吴就业

无损上下线是服务治理不可忽视的问题，在应⽤上下线发布过程中，如果上下线不平滑，就会出现短时间的服务调⽤报错，如连接被拒绝（Connection refused）、请求超时或请求异常。

对于线上应用，出现进程自动挂掉的原因，如果可以排除因程序本身原因，那么很大可能性是因为操作系统内存不够用，进程被操作系统kill掉了。 那如何确认是否是被操作系统kill掉的呢？

此次性能测试对比的是我们基于Dubbo扩展点自实现的Http rpc协议，与Dubbo原生Dubbo rpc协议的单次请求响应平均耗时、吞吐量。

适用于虚拟机，容器下受权限限制，无法使用。 前提条件 在编译go项目时，使用go build -gcflags "all=-N -l"，关闭内联优化，以支持debug。

泛化调用需要消费者在调用之前，指定调用的目标接口类名、方法名、方法参数类型，并将pojo参数转为map，提供者响应结果如果是pojo，也需要转为map。

Dubbo的分层架构，提供的各层扩展点，让Dubbo具备了优秀的扩展性。我们基于Dubbo二次开发，借助Registry扩展点、RouterFactory扩展点实现了跨业务RPC调用。

使用规则引擎感觉太重，不如试试这个轻量级的条件表达式匹配引擎。支持sql语言中where语句的表达式写法。

MySQL5.6之后，已经支持TIME、DATETIME和TIMESTAMP类型保存精度到微秒，但要求在创建表的时候，声明字段类型时，需要给TIME、DATETIME或TIMESTAMP加上fsp。

如果同一时刻需要下发几百个执行job的请求给执行器，使用这种阻塞的RPC，意味着需要开启几百个线程，使用几百个连接发送请求，而这几百个线程都需要阻塞等待响应，Job越多，需要的线程数就越多。