-
Notifications
You must be signed in to change notification settings - Fork 0
/
StarFish之SpringCloud选型背景.log
129 lines (122 loc) · 10.9 KB
/
StarFish之SpringCloud选型背景.log
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
关于《基础环境选型指南》修订增加Spring Cloud技术选型的提案
1. 背景
1.1. 基本情况
在大数据、互联网等场景下，软件系统的复杂持续提升，系统运维管理的要求也越来越高，需要技术架构能够满足服务的集群调度、弹性伸缩、灰度发布，以及对服务进行限流、熔断控制方面的要求。
公司软件开发中已有在使用Spring Cloud框架，但框架具体的选型、版本没有明确要求，面向不同技术点的选型来开展统一管理和治理的工作显然是不可行的，需要对治理相关的核心技术选型进行统一。
1.2. 解决措施
统一Spring Cloud框架的关键技术及版本的选型，基于Spring Cloud提供的服务治理技术方案，提升技术架构在服务治理方面的能力。
2. 提案
2.1. 方案描述
Spring作为Java开发技术事实标准，Spring Cloud和Spring基于同一个体系，使用Spring Cloud框架，研发学习掌握的门槛较低，有利于技术的推广。
公司软件开发目前较多使用Spring Cloud Edgware版本，但该版本生命周期已经结束，考虑未来的使用，选型Spring Cloud Hoxton.SR2版本，相应的Spring Boot版本选型为2.2.x。
服务注册中心选型为Consul 1.6.x.Consul为已有的基础环境选型，本次主要进行版本更新，以获得更好的安全漏洞修复及特性支持，新版本向下兼容原有选型版本。
负载均衡框架选用Ribbon，RPC框架选用Feign，两者都是目前产品中主流使用的。
服务熔断限流框架选用Resilience4j。公司已有产品中使用Hystrix，但Hystrix官方已停止维护，官方推荐Resilience4j作为Hystrix替代品。
监控框架选型为Actuator。使用该库的健康检查接口作为Consul默认健康状态检查接口，来检测服务的健康状态。
JVM应用度量框架选用MicroMeter。通过MicroMeter可以无缝对接Prometheus监控服务。
调用链库选型为Sleuth。主要考虑与调用链服务选型Zipkin对齐。
2.2. 可行性评估
Spring Cloud在业内以及公司的大量产品中都普遍使用，方案成熟。
考虑将目前核心服务的服务目录选型替换为Consul，主要产品的迁移考虑一次性完成。在项目场景下，新组件通过老版本目录服务寻址其他服务，由脚手架提供向下兼容的方案；老组件通过新版本目录服务寻址其他服务，目录服务提供适配层进行老协议兼容。具体兼容性方案会在规范实施前验证和发布。
2.3. 规范修订
2.3.1. 修订《基础环境选型指南》增加Spring Cloud选型
增加4.1.1.3章节：
4.1.1.3 Spring Cloud
4.1.1.3.1 许可协议
Apache License 2.0许可证，宽松的开源许可协议，可免费用于商业用途。
4.1.1.3.2 选型原则
Spring Cloud版本选型为Hoxton.x，最低版本号为Hoxton.SR2。相应的Spring Boot版本选型为2.2.x。
子模块选型：
服务注册中心选型为Consul，版本见Consul选型。
负载均衡框架选用Ribbon，版本由Spring Cloud版本决定。
RPC框架选用Feign，版本由Spring Cloud版本决定。
服务熔断限流框架选用Resilience4j，版本由Spring Cloud版本决定。
监控框架选型为Actuator，版本由Spring Boot版本决定。
JVM应用度量框架选用MicroMeter，版本由Spring Boot版本决定。
调用链库选型为Sleuth，版本由Spring Boot版本决定。
4.1.1.3.3 跨平台支持
支持本文档选型中的Windows Server和Linux平台（可运行在基本所有主流操作系统上）。
4.1.1.3.3 使用场景
用于Java 微服务架构开发。
2.3.2. 修订《基础环境选型指南》修改Consul选型版本
修改3.1.9.1章节：
3.1.9.1 Consul
3.1.9.1.1 许可协议
MPL2.0许可证，是较宽松的开源许可协议，免费并允许商业目的使用。
3.1.9.1.2 选型原则
选型版本：Consul 1.6.x。最低选用版本为1.6.2（Windows/Linux）。
Consul是开源的一个使用go语言开发的服务注册发现、配置管理中心服务，内置了服务注册与发现框 架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案，不再需要依赖其他工具（比如ZooKeeper等）。
由于采用go语言开发，所有依赖都编译到了可执行程序中，只有一个可运行的二进制的包，服务部署简单。
Consul部署时分Server节点和Client节点（通过不同的启动参数区分），Server节点做Leader选举和数据一致性维护，Client节点部署在服务机器上，作为服务程序访问Consul的接口。每个数据中心官方建议需要3或5个Server节点以保证数据安全，同时保证Server-Leader的选举能够正确的进行。
Consul提供Restful API，跨语言编程实现简单。
3.1.9.1.3 跨平台支持
支持本文档选型中的Windows Server和Linux平台（可运行在基本所有主流操作系统上）。
关于《基础环境选型指南》修订增加RabbitMQ的提案
1. 背景
1.1. 基本情况
随着系统设计对消息中间件可用性、可扩展性、安全性及性能方面的要求越来越高，当前选型的ActiveMQ已经很难满足这些需求。
RabbitMQ在公司部分产品线也有使用，在覆盖ActiveMQ使用场景基础上，更能满足上述新的需求。同时维持两种实现也带来在开发、维护、管理方面的重复投入。
1.2. 解决措施
消息中间件技术选型增加RabbitMQ，并在公司内作为默认选型进行推广，逐步替代原有的ActiveMQ。
2. 提案
2.1. 现有技术方案分析
2.1.1. ActiveMQ
Apache ActiveMQ是Apache软件基金会所研发的开放源代码消息中间件，支持Spring Framework，支持集群，但集群性能较低且存在较多安全性问题。为公司当前消息中间件默认选型版本。
2.1.2. RabbitMQ
RabbitMQ是实现了高级消息队列协议（AMQP）的消息中间件，支持集群，集群可用性、性能、吞吐量高，在公司部分产品线已经成熟应用。
2.1.3. RocketMQ
RocketMQ是阿里巴巴在2012年开源的分布式消息中间件，支持集群，在高吞吐、低延迟、高可用上有着非常好表现，但生态成熟度还不高，目前在公司使用率较低。
2.2. 方案选择分析
2.2.1. 方案选择
ActiveMQ 得分 RabbitMQ 得分 RocketMQ 得分
高可用
（10分） 1)基于主从架构实现高可用，但官方推荐的方案需要引入共享文件系统，方案较重。
2)LevelDB+ZooKeeper方案已经被官方废弃，后续得不到维护。 6 通过mirrored queues提供支持。 8 非常高，分布式架构，确保可用性。 9
集群
（10分） 支持通过Broker的network互连实现，实际验证发现随着节点增加性能递减比较明显，且集群运维困难。 6 基于Erlang编写，Erlang语言天生具备分布式特性，故RabbitMQ天然支持集群。 8 支持比较完备，本身为分布式架构。 9
资源消耗
（10分） 默认内存资源消耗为500MB，随着连接增加内存增加曲线较陡峭。 6 默认内存资源消耗为150MB,随着连接增加，内存增长趋势较平缓。 8 资源消耗相对RabbitMQ较大，和ActiveMQ类似。 6
安全性
（10分） 安全缺陷相对较多。 6 安全缺陷较少。 8 安全缺陷相对较少。 7
性能
（10分） ActiveMQ在队列数多的场景下性能较差，队列数量达到上千时，消息延迟达到秒级，单机吞吐量支持3000/s。 6 消息延迟为微秒级。队列数量对性能影响小，单机性能能够达到7000/s。 8 集群并发能力强，消息延迟毫秒级。可用性、性能高。 10
技术社区活跃度
（10分） ActiveMQ5.x官方维护逐渐减少，处于生命周期尾期。 7 社区活跃,且在互联网公司应用较多。 10 产品较新文档比较缺乏，社区活跃度一般。 5
客户端支持能力
（10分） 支持Java, C, C++, C#，符合公司当前主流客户端业务需求。 9 官方支持Erlang、Java、Ruby，社区产出多种语言API，包含C,C++等，符合公司当前业务需要。 9 官方支持Java，
C++客户端还不成熟。 4
管理监控能力
（10分） 基于jmx的监控接口，jmx端口本身存在安全风险，在产品中默认需要关闭。 8 有更加完善的监控手段，支持通过Http-API获取服务监控信息。 10 支持通过监控RocketMQ Java进程的运行情况获取监控信息。 10
总分 54 69 60
根据以上方案比对，并结合公司消息中间件的使用情况，选择RabbitMQ版本3.8.x，作为默认选型进行推广。
2.2.2. 可行性评估
RabbitMQ在公司社区管理平台、智能应用平台等产品已有使用，方案成熟。从消息模型上RabbitMQ的能够支持目前应用所用的Queue和Topic模型。RabbitMQ存在丰富客户端库，包括C++、java、python，改造门槛较低。
消息中间件在当前产品中，主要用在组件与核心服务、组件与组件之间的消息集成，以及组件和大数据服务之间的数据交换，具体使用情况如下：
场景 云远构架 域见构架
业务组件和业务组件消息通讯 RabbitMQ ActiveMQ
业务组件和通用组件消息通讯 ActiveMQ ActiveMQ
组件和核心服务消息通讯 ActiveMQ ActiveMQ
组件和大数据服务数据交换 Kafka Kafka
本次选型改造，涉及前三种消息集成场景，考虑通过升级核心服务通知SDK、脚手架适配的方式，进行两种选型的兼容，以支持产品能够在两种选型中进行过渡，具体迁移方案在规范实施前发布。
2.3. 规范修订
2.3.1. 修订《基础环境选型指南》增加RabbitMQ选型
增加3.1.6.1章节：
3.1.6.1 RabbitMQ
3.1.6.1.1 许可协议
MPL1.1协议，许可证，是较宽松的开源许可协议，免费并允许商业目的使用。
3.1.6.1.2 选型原则
选型版本：RabbitMQ 3.8.x。
RabbitMQ是实现了高级消息队列协议（AMQP）的消息中间件，支持集群，集群可用性。同时通过鉴权、授权机制可以实现topic级别的权限控制。性能方面并发能力较强，消息延迟为微秒级。队列数量对性能影响小，单机性能能够达到7000/s。
新开发软件应该优先考虑该选型。
3.1.6.1.3 跨平台支持
支持本文档选型中的Windows Server和Linux平台（可运行在基本所有主流操作系统上），支持x86、ARM等多种处理器架构。
2.3.2. 修订《基础环境选型指南》修改ActiveMQ选型原则
3.1.6.2 ActiveMQ
3.1.6.2.1 许可协议
Apache许可证，是较宽松的开源许可协议，免费并允许商业目的使用。
3.1.6.2.2 选型原则
选型版本：ActiveMQ 5.14.x x86_64。最低选用版本为5.14.5（当前技术选型时的5.14.x系列的最新版本）。该选型作为迁移过渡存在，新开发软件应优先考虑RabbitMQ。
3.1.6.2.3 跨平台支持
支持本文档选型中的Windows Server和Linux平台（可运行在基本所有主流操作系统上）。并且提供C/C++、Java等多种编程接口。
3.1.6.2.4 使用场景/约束
必需开启用户认证模式，禁止按默认的无认证模式使用。