drools 用户指南 ----Methods vs Rules

  规则引擎2 分钟读完 (大约246个字)

Methods vs Rules

人们经常混淆方法和规则，初学者经常会问：“我如何理解规则的含义？“ 在最后一节之后，你会对规则的使用得心应手，答案也变得显而易见的，但在这之前，先让我们总结一下方法判断和规则的差异。

1
2
3
4
5
public void helloWorld(Person person) {
    if (person.getName().equals("Chuck") ) {
        System.out.println("Hello Chuck");
    }
}
 
  阅读更多

drools 用户指南 ----stateless session（无状态会话）的使用

  规则引擎10 分钟读完 (大约1472个字)

stateless session 无状态会话

Drools 规则引擎中有如此多的用例和诸多功能，它变得令人难以置信。不过不用担心，复杂性是分层的，你可以用简单的用例来逐步了解 drools。

无状态会话，不使用推理，形成最简单的用例。无状态会话可以被称为函数传递一些数据，然后再接收一些结果。无状态会话的一些常见用例有以下但不限于：

  1. 验证
    这个人有资格获得抵押吗？
  2. 计算
    计算抵押保费。
  3. 路由和过滤
    将传入的邮件（如电子邮件）过滤到文件夹中。
    将传入的邮件发送到目的地。

所以让我们从使用驾驶执照应用程序的一个非常简单的例子开始吧。

1
2
3
4
5
6
public class Applicant {
    private String name;
    private int age;
    private boolean valid;
    // getter and setter methods here
}

现在我们有了我们的数据模型，我们可以写出我们的第一个规则。我们假设应用程序使用规则来拒绝不符合规则的申请。由于这是一个简单的验证用例，我们将添加一条规则来取消任何 18 岁以下的申请人的资格。

1
2
3
4
5
6
7
8
package com.company.license

rule "Is of valid age"
when
    $a : Applicant(age < 18)
then
    $a.setValid(false);
end
 
  阅读更多

drools 用户指南 ----stateful session（有状态会话）的使用

  规则引擎11 分钟读完 (大约1658个字)

stateful session 有状态会话

有状态会话长期存在，并允许随着时间的推移进行迭代更改。 有状态会话的一些常见用例包括但不限于：

  1. 监测
    半自动买入股票市场监控与分析。
  2. 诊断
    故障查找，医疗诊断
  3. 物流
    包裹跟踪和送货配置
  4. 合规
    验证市场交易的合法性。

与无状态会话相反，必须先调用 dispose() 方法，以确保没有内存泄漏，因为 KieBase 包含创建状态知识会话时的引用。 由于状态知识会话是最常用的会话类型，所以它只是在 KIE API 中命名为 KieSession。 KieSession 还支持 BatchExecutor 接口，如 StatelessKieSession，唯一的区别是 FireAllRules 命令在有状态会话结束时不被自动调用。

我们举例说明了用于提高火灾报警器的监控用例。 只使用四个类，我们假设 Room 代表房子里的房间，每个 Room 都有一个喷头 Sprinkler。 如果在房间里发生火灾，我们用一个 Fire 实例来表示, 用 Alarm 代表警报 。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class Room {
    private String name
    // getter and setter methods here
}

public class Sprinkler {
    private Room room;
    private boolean on;
    // getter and setter methods here
}

public class Fire {
    private Room room;
    // getter and setter methods here
}

public class Alarm {
}

在上一节无状态会话中介绍了插入和匹配数据的概念。 这个例子假设每个对象类型的都是单个实例被插入的，因此只使用了字面约束。 然而，房子有许多房间，因此 rules 必须表达实体类之间的关系，例如在某个房间内的喷洒器。 这最好通过使用绑定变量作为模式中的约束来完成。 这种“加入”过程产生了所谓的“cross products”，这在下一节中将会介绍。

 
  阅读更多

Zuul 性能测试

  网关 / Zuul12 分钟读完 (大约1778个字)

环境准备

采用三台阿里云服务器作为测试
10.19.52.8 部署网关应用 -gateway
10.19.52.9, 10.19.52.10 部署用于测试的业务系统
这里写图片描述

压测工具准备

选用 ab 作为压力测试的工具，为了方便起见，直接将 ab 工具安装在 10.19.52.8 这台机
测试命令如下：

1
ab -n 10000 -c 100 http://10.19.52.8:8080/hello/testOK?access_token=e0345712-c30d-4bf8-ae61-8cae1ec38c52

其中－n 表示请求数，－c 表示并发数, 上面一条命令也就意味着，100 个用户并发对 http://10.19.52.8/hello/testOK 累计发送了 10000 次请求。

服务器, 网关配置

由于我们使用的 tomcat 容器，关于 tomcat 的一点知识总结如下：

 
  阅读更多

Zuul 动态路由

  网关 / Zuul21 分钟读完 (大约3137个字)

前言

Zuul 是 Netflix 提供的一个开源组件, 致力于在云平台上提供动态路由，监控，弹性，安全等边缘服务的框架。也有很多公司使用它来作为网关的重要组成部分，碰巧今年公司的架构组决定自研一个网关产品，集动态路由，动态权限，限流配额等功能为一体，为其他部门的项目提供统一的外网调用管理，最终形成产品 (这方面阿里其实已经有成熟的网关产品了，但是不太适用于个性化的配置，也没有集成权限和限流降级)。

不过这里并不想介绍整个网关的架构，而是想着重于讨论其中的一个关键点，并且也是经常在交流群中听人说起的：动态路由怎么做？

再阐释什么是动态路由之前，需要介绍一下架构的设计。

传统互联网架构图

这里写图片描述
上图是没有网关参与的一个最典型的互联网架构 (本文中统一使用 book 代表应用实例，即真正提供服务的一个业务系统)

加入 eureka 的架构图

这里写图片描述
book 注册到 eureka 注册中心中，zuul 本身也连接着同一个 eureka，可以拉取 book 众多实例的列表。服务中心的注册发现一直是值得推崇的一种方式，但是不适用与网关产品。因为我们的网关是面向众多的 ** 其他部门 ** 的 ** 已有 ** 或是 ** 异构架构 ** 的系统，不应该强求其他系统都使用 eureka，这样是有侵入性的设计。

最终架构图

这里写图片描述
要强调的一点是，gateway 最终也会部署多个实例，达到分布式的效果，在架构图中没有画出，请大家自行脑补。

本博客的示例使用最后一章架构图为例，带来动态路由的实现方式，会有具体的代码。

 
  阅读更多

分布式限流

  架构设计12 分钟读完 (大约1736个字)

前言

最近正在为本科论文的事感到心烦，一方面是在调研期间，发现大部分的本科论文都是以 MVC 为架构，如果是使用了 java 作为开发语言则又是千篇一律的在使用 SSH，二方面是自己想就微服务，分布式方面写一篇论文，讲述一些技术点的实现，和一些中间件的使用，看到如八股文般的模板格式.. 不免让人望文生怯。退一步，投入模板化 ssh-web 项目的怀抱，落入俗套，可以省去自己不少时间，因为在外实习，琐事并不少；进一步，需要投入大量时间精力去研究，而且不成体系，没有论文参考。

突然觉得写博客，比写论文爽多了，可以写自己想写的，记录自己最真实的想法。可能会逐渐将之前博客维护的自己的一些想法，纳入到本科论文中去。

经典限流算法

 
  阅读更多

DevOps 的八荣八耻

  架构设计35 分钟读完 (大约5241个字)

前言

被群里的好友安利了一发，周日跑去参加了一个技术讲座《云上开发与运维最佳实践》，听完两个人的演讲之后才发现主题竟然是讲运维，好在有一个人干货不少，在此记录下所得。简单追溯了一下这个 DevOps 才发现并不是一个新的概念，早在 2010 年就能看到有相关的人在追捧这个概念了。DevOps 就是开发（Development）和运维（Operations）这两个领域的合并。（如果没错的话，DevOps 还包括产品管理、QA、winces 甚至销售等领域）。这种理念和现如今流行的微服务架构以及分布式特性的相关理念不谋而合。这篇文章主要就是转载记录了当时又拍云运维总监的演讲稿。

DevOps 的八荣八耻

 
  阅读更多

java 并发实践 --ConcurrentHashMap 与 CAS

  JAVA11 分钟读完 (大约1680个字)

前言

最近在做接口限流时涉及到了一个有意思问题，牵扯出了关于 concurrentHashMap 的一些用法，以及 CAS 的一些概念。限流算法很多，我主要就以最简单的计数器法来做引。先抽象化一下需求：统计每个接口访问的次数。一个接口对应一个 url，也就是一个字符串，每调用一次对其进行加一处理。可能出现的问题主要有三个：

  1. 多线程访问，需要选择合适的并发容器
  2. 分布式下多个实例统计接口流量需要共享内存
  3. 流量统计应该尽可能不损耗服务器性能

但这次的博客并不是想描述怎么去实现接口限流，而是主要想描述一下遇到的问题，所以，第二点暂时不考虑，即不使用 redis。

说到并发的字符串统计，立即让人联想到的数据结构便是 ConcurrentHashpMap<String,Long> urlCounter;

 
  阅读更多

volatile 疑问记录

  JAVA4 分钟读完 (大约666个字)

对 java 中 volatile 关键字的描述，主要是 可见性 和 有序性 两方面。

一个很广泛的应用就是使得多个线程对共享资源的改动变得互相可见，如下：

 
  阅读更多

浅析 java 内存模型（JMM）

  JAVA24 分钟读完 (大约3630个字)

并发编程模型的分类

在并发编程中，我们需要处理两个关键问题：线程之间如何通信及线程之间如何同步（这里的线程是指并发执行的活动实体）。通信是指线程之间以何种机制来交换信息。在命令式编程中，线程之间的通信机制有两种：共享内存和消息传递。

在共享内存的并发模型里，线程之间共享程序的公共状态，线程之间通过写 - 读内存中的公共状态来隐式进行通信。在消息传递的并发模型里，线程之间没有公共状态，线程之间必须通过明确的发送消息来显式进行通信。

同步是指程序用于控制不同线程之间操作发生相对顺序的机制。在共享内存并发模型里，同步是显式进行的。程序员必须显式指定某个方法或某段代码需要在线程之间互斥执行。在消息传递的并发模型里，由于消息的发送必须在消息的接收之前，因此同步是隐式进行的。

Java 的并发采用的是共享内存模型，Java 线程之间的通信总是隐式进行，整个通信过程对程序员完全透明。如果编写多线程程序的 Java 程序员不理解隐式进行的线程之间通信的工作机制，很可能会遇到各种奇怪的内存可见性问题。

 
  阅读更多
Kirito的技术分享
↑关注微信公众号↑

链接

最新文章

分类

Your browser is out-of-date!

Update your browser to view this website correctly.&npsb;Update my browser now

×

×