|Service Framework Composition
The most basic service framework
The basic service-oriented framework includes the following modules: unified RPC framework, service registry, and management platform.
With these three modules, the basic service can be realized. The three modules are analyzed in detail below.
RPC framework selection
Why it must be a unified RPC framework, not just any framework, here is mainly for technical alignment, reducing the learning cost of developers, and reducing the cost of communication between teams.
OK, so what do we need to consider when choosing an RPC framework?
Here I summarize:
-
Code specification: for example, is it transparent to existing code or code generation;
-
Communication protocol: for example, TCP or HTTP;
-
Serialization protocol: such as binary or text, whether it needs to be cross-language, performance;
-
IO model: asynchronous/synchronous, blocking/non-blocking;
-
Load balancing: client soft load, proxy mode, server load.
In addition, if we choose from open source, then we also need to consider:
-
Maturity: including learning cost, community popularity, number of documents, whether there is team maintenance, stability (blind pursuit is not necessarily the most suitable);
-
Scalability: whether there is SPI support for expansion, whether it supports up and down compatibility;
-
Cross-language: whether to support cross-language;
-
Performance: To be an RPC framework, the performance is generally not too bad [funny face].
The following is a comparison of some common open source frameworks, you can take a look.
thrift
RESTful
dubbo
gRPC
| code specification |
IDL code generation based on Thrift |
Based on the JAX-RS specification |
codeless hacking |
Generate code based on .Proto |
| Protocol |
TCP |
HTTP |
TCP |
HTTP/2 |
| serialization protocol |
thrift |
JSON |
Multi-protocol support, default hessian |
protobuf |
| IO framework |
Thrift comes with |
Servlet container |
Netty3 |
Netty4 |
| load balancing |
without |
without |
Client soft load |
without |
| cross language |
multilingual |
multilingual |
Java |
multilingual |
| Scalability |
generally |
Okay |
Okay |
Difference |
Ps: SOAP, RMI, Hessian, ICE are not listed.
Selection summary:
-
If you need to interact with the front end, it is suitable for short links and cross-language RPC frameworks, such as RESTful, gRPC, etc.;
-
If it is purely background interaction, RPC frameworks suitable for long links and serialized into binary, such as thrift, dubbo, etc., are more efficient;
-
If it is a small company, the new company promotes the service framework from scratch, and can choose a standardized RPC framework, such as thrift, RESTful, gRPC;
-
如果是已有大量业务代码的再推广服务框架的，那么最好选择无代码入侵的RPC框架，例如dubbo、RESTful。
注册中心选型
注册中心相当于是服务提供者和服务调用者之间的引路人，在服务治理中的作用极为重要。
选择注册中心基本要考量：
-
服务注册：接收注册信息的方式；
-
服务订阅：返回订阅信息的方式，推还是拉；
-
状态检测：检测服务端存活状态。
重点提一下这个状态检测，因为这个要是检测不准确会误判，导致严重后果，例如Zookeeper根据服务端注册的临时节点进行状态检测，如果服务端和Zookeeper之间的网络闪断，导致Zookeeper认为服务端已经死了，从而摘掉这个节点；但是其实客户端和服务端直接的网络是好的，这样就有可能把节点全部摘掉，导致无可用节点。
如果是从开源里面选择，那么还需要考量：
-
成熟度：包括学习成本，社区热度，文档数（盲目追求的不一定是最适合）；
-
维护成本：注册中心维护；
-
数据解构：是否能快速定位结果，是否能遍历；
-
性能和稳定性；
-
CAP原则：CP（关注一致性）还是AP（关注可用性）。
下面是常见的一些使用开源项目做注册中心的比较，大家可以看一下。
ZooKeeper
etcd
Consul
Eureka
| 一致性 |
强一致性paxos |
强一致性Raft |
强一致性Raft |
弱一致性 |
| 数据结构 |
Tree |
K/V |
K/V |
K/V |
| 通讯协议 |
TCP |
HTTP、gRPC |
HTTP、DNS |
HTTP |
| 客户端 |
ZKClient |
/ |
/ |
Eureka-client |
| CAP原则 |
CP |
CP |
CP |
AP |
Ps：Redis和MySQL没有列举。
选型小结：
-
规模小选择CP，RPC框架可以直接接入数据源；
-
规模大选择AP， RPC框架不可以直接接入数据源；
-
存在跨机房，跨地域的尽量不要选有强一致性协议的注册中心；
-
RPC框架必须要有注册中心不可用的容灾策略；
-
服务状态检测十分重要。
简易管理端
管理端没啥特殊要求，最起码能看到服务提供者和调用者即可。
|完善的服务化框架
如果需要一个完善的服务化框架，那么必须增加外部模块，常见的模块如下图：
接口文档管理
提供一个接口文档管理以及接口查询的入口，可以是一个公共的WIKI，也可以是独立的系统，等等。
这里可以定义接口的文档，包括接口描述，方法定义，字段定义。可以定义接口的SLA，包括支持的并发数，tp99多少，建议配置是什么。还有就是接口的负责人等一些查询的入口。
配置中心
提供一个配置管理的地方，这里说的配置主要指的是服务相关的一些配置。
配置包括分组配置、路由策略、黑白名单、降级开关、限流信息、超时时间、重试次数等等，任何可以动态变更的所有数据。
这样服务提供者和服务调用者可以不需要重启自己的应用，直接进行配置的变更。
配置中心可以独立于注册中心，也可以和注册中心合并。
监控中心
监控服务关注接口维度，实例（例如所在JVM实例）维度的数据。RPC框架可以定时上报调用次数，耗时，异常等信息。监控中心可以统计出服务质量信息，也可以进行监控报警。
分布式跟踪
区别于监控中心，以调用链的模式对服务进行。RPC框架作为分布式跟踪系统的一个天然埋点，可以很好的进行一个数据输出。
服务治理（重点）
我这边列了常见的服务治理功能，例如：
-
服务路由：
-
权重：例如机器配置高的权重高，机器配置低的权重低；
-
IP路由：例如某几台机器只能调某几台机器；
-
分组路由：例如自动根据配置调某个分组；
-
参数路由：例如根据方法名进行读写分类，或者根据参数走不同的节点；
-
机房路由：例如只走同机房，或者同机房优先。
调用授权：
-
应用授权：只有授权后的应用才能调这组服务
-
token：只有token对的调这组服务
-
黑白名单：只有名单允许的才能调这组服务
动态分组：
-
服务端切分组：可以根据分组的情况，对服务提供者进行一个动态的分组调度；
-
客户端切分组：可以对调用者进行一个分组调度。
调用限流：
-
服务端限流：服务端基于令牌桶或者漏桶模型进行限流；
-
客户端限流：根据客户端的标识，进行调用次数限流。
灰度部署：
-
灰度上线：先启动，验证后在提供服务；
-
预发标识：表示该服务为预发布服务；
-
接口测试：方便的提供接口自动化功能测试功能。
配置下发：
-
服务配置；
-
全局配置。
服务降级：
-
Mock：出现异常或者测试情况下，返回Mock数据；
-
熔断：客户端超时或者服务端超时；
-
拒绝服务：服务端压力大时，自动拒绝服务，保护自己。
网关
RPC框架大部分场景都是自己调用的，什么时候会需要一个网关呢？
网关可以提供如下功能：
-
统一的鉴权服务；
-
限流服务；
-
协议转换：外部协议转统一内部协议；
-
Mock：服务测试，降级等；
-
其它一些统一处理逻辑（例如请求解析，响应包装）。
服务注册中心Plus
需要逻辑处理能力，例如对数据进行筛选过滤整合，计算服务路由等功能
同时还需要有与RPC框架交互的功能。
管理端Plus
管理端除了之前的简单服务管理功能外，还需要提供配置信息展示，监控信息展示，各种维度的数据展示。也就是下面提到的服务治理功能，都可以在管理端进行管理。另外，常见的服务治理功能，我们都可以作为开放服务供开发人员进行一个调用。
http://mp.weixin.qq.com/s?__biz=MzIwODA4NjMwNA==&mid=2652898121&idx=1&sn=5463a399a324cd48114a85b0bc0e984f&chksm=8cdcd706bbab5e10707e1be071f24a1338e000c9e796a40f66716a205df2ac69868eea66d763&mpshare=1&scene=23&srcid=12220hyf5Y3Hp84IjQUnQsmP#rd