微服务2.0技术栈选型手册

• 选型准则

1. 生产级：选择的产品是要抗流量解决实际业务问题的，并非只是拿来写demo，该产品必须是可运维、可治理，成熟稳定的。
2. 一线互联网公司落地产品
3. 开源社区活跃度

• 微服务基础架构核心关注点

• 服务框架选型

1. SpringBoot/Cloud由于spring社区的影响力以及Netflix的背书，目前可以认为是Java微服务的一个社区标准。基于Spring的框架本质上可以认为是Restful框架，序列化协议主要采用基于文本的JSON，通信协议基于HTTP。
2. Dubbo，其本质是一套基于Java的RPC框架，当当的DubboX拓展了RESTful的接口暴露能力，它主要面向Java技术栈，跨语言能力较弱，其强大的服务治理能力也导致了框架相对较重，完全用好的门槛较高。另，新浪微博开源的Motan也不错，像是一个轻量剪裁版的Dubbo。
3. gRpc，是谷歌近年新推的一套RPC框架，基于protobuf的强契约编程模型，能自动生成各种语言客户端，且保证互操作。支持HTTP2是一大亮点，但比较适合内部服务调用场景，对外暴露服务比较麻烦，需要配合gRpc gateway，另，东西比较新，对于HTTP2带来的好处社区也未达成一致，请慎用。

• 运行时支撑服务选型

1. 服务注册中心，springcloud与Euark是最佳搭配，Eureka在Netflix经过大规模生产验证，支持跨数据中心，客户端配合Ribbon可以实现灵活的客户端软负载；Consul[附录12.5]也是不错选择，天然支持跨数据中心，还支持KV模型存储和灵活健康检查能力，目前在github上有超过11k星
2. 服务网关，如果采用Spring Cloud体系，则选择Zuul[附录12.6]是最佳搭配，Zuul在Netflix经过大规模生产验证，支持灵活的动态过滤器脚本机制，异步性能不足（基于Netty的异步Zuul迟迟未能推出正式版）。Zuul网关目前在github上有超过3.7k星。基于Nginx/OpenResty的API网关Kong[附录12.7]目前在github上比较火，有超过14.1k星。因为采用Nginx内核，Kong的异步性能较强，另外基于lua的插件机制比较灵活，社区插件也比较丰富，从安全到限流熔断都有，还有不少开源的管理界面，能够集中管理Kong集群。
3. 配置中心，Spring Cloud自带Spring Cloud Config[附录12.8]（github 0.75k stars），个人认为算不上生产级，很多治理能力缺失，小规模场景可以试用。个人比较推荐携程的Apollo[附录12.9]配置中心，在携程经过生产级验证，具备高可用，配置实时生效（推拉结合），配置审计和版本化，多环境多集群支持等生产级特性，建议中大规模需要对配置集中进行治理的企业采用。Apollo目前在github上有超过3.4k星

• 服务监控选型

1. 日志监控，ELK目前可以认为是日志监控的标配，功能完善开箱即用，Elasticsearch[附录12.10]目前在github上有超过28.4k星。Elastalert[附录12.11] (github 4k stars)是Yelp开源的针对ELK的告警通知模块。
2. 调用链监控，目前社区主流是点评CAT[附录12.12]（github 4.3k stars），Twitter之前开源现在由OpenZipkin社区维护的Zipkin[附录12.13]（github 7.5k stars）和Naver开源的Pinpoint[附录12.14]（github 5.3k stars）。
3. Metrics监控主要依赖于时间序列数据库(TSDB)，目前较成熟的产品是StumbleUpon公司开源的基于HBase的OpenTSDB。OpenTSDB 本身不提供告警模块，Argus[附录12.17]（github 0.29k星）是Salesforce开源的基于OpenTSDB的统一监控告警平台，支持丰富的告警函数和灵活的告警配置，可以作为OpenTSDB的告警补充。年也出现一些轻量级的TSDB，如InfluxDB[附录12.18]（github 12.4k stars）和Prometheus[附录12.19]（github 14.3k stars），这些产品函数报表能力丰富，自带告警模块，但是分布式能力不足，适用于中小规模企业。Grafana[附录12.20]（github 19.9k stars）是Metrics报表展示的社区标配。
4. 健康检查和告警通知，Sensu[附录12.21]（github 2.7k stars），能够对各种服务（例如spring boot暴露的健康检查端点，时间序列数据库中的metrics，ELK中的错误日志等）定制灵活的健康检查(check)，然后用户可以针对check结果设置灵活的告警通知策略。Sensu在Yelp等公司有落地案例。其它类似产品还有Esty开源的411[附录12.22]（github 0.74k星）和Zalando的ZMon[附录12.23] (github 0.15k星)，它们是分别在Esty和Zalando落地的产品，但是定制check和告警配置的使用门槛比较高，社区不热，建议有定制自研能力的团队试用。ZMon后台采用KairosDB存储，如果企业已经采用KariosDB作为时间序列数据库，则可以考虑ZMon作为告警通知模块。

• 服务容错选型

1. 针对Java技术栈，Netflix的Hystrix[附录12.24]（github 12.4k stars）把熔断、隔离、限流和降级等能力封装成组件，任何依赖调用（数据库，服务，缓存）都可以封装在Hystrix Command之内，封装后自动具备容错能力。

2. Hystrix一般需要在应用端或者框架内埋点，有一定的使用门槛。对于采用集中式反向代理（边界和内部）做服务路由的公司，则可以集中在反向代理上做熔断限流，例如采用nginx[附录12.25]（github 5.1k stars）或者Kong[附录12.7]（github 11.4k stars）这类反向代理，它们都有插件支持灵活的限流容错配置。Zuul网关也可以集成Hystrix实现网关层集中式限流容错。集中式反向代理需要有一定的研发和运维能力，但是可以对限流容错进行集中治理，可以简化客户端。

• 后台服务选型

1. 消息系统，Apache顶级项目Kafka[附录12.26]（github 7.2k stars）是社区标配。对 Kafka的监控和治理能力进行适当定制完善，Allegro公司开源的hermes[附录12.27]（github 0.3k stars）是一个可参考项目，它在Kafka基础上封装了适合业务场景的企业级治理能力。阿里开源的RocketMQ；RabbitMQ[附录12.29]（github 3.6k星）是老牌经典的MQ，队列特性和文档都很丰富，性能和分布式能力稍弱，中小规模场景可选。
2. 缓存治理，客户端直连模式，SohuTv开源的cachecloud[附录12.30]（github 2.5k stars）是一款不错的Redis缓存治理平台，提供诸如监控统计，一键开启，自动故障转移，在线伸缩，自动化运维等生产级治理能力，另外其文档也比较丰富。中间层Proxy模式，则Twitter开源的twemproxy[附录12.31]（github 7.5k stars）和CodisLab开源的codis[附录12.32]（github 6.9k stars）是社区比较热的选项。
3. 分布式数据访问层，采用Java技术栈，则当当开源的shardingjdbc[附录12.33]（github 3.5k stars）是一个不错的选项，如果倾向采用数据库访问中间层proxy模式，则从阿里Cobar演化出来的社区开源分库分表中间件MyCAT[附录12.34]（github 3.6k stars）是一个不错选择 。
4. 任务调度系统，xxl-job[附录12.35]（github 3.4k stars），部署简单轻量，大部分场景够用。elastic-job[附录12.36]（github 3.2k stars）相比xxl-job功能更强一些也更复杂。

• 服务安全选型

1. 对于微服务安全认证授权机制一块，目前业界虽然有OAuth和OpenID connect等标准协议。
2. Apereo CAS
3. Boss开源的keycloak[附录12.38]（github 1.9 stars），spring cloud security[附录12.39]等，大都是opinionated（一家观点和做法）的产品，同时因支持太多协议造成产品复杂，也缺乏足够灵活性。
4. 个人建议基于OAuth和OpenID connect标准，在参考一些开源产品的基础上（例如Mitre开源的OpenID-Connect-Java-Spring-Server[附录12.40]，github 0.62k stars），定制自研轻量级授权服务器。
5. Wso2提出了一种微服务安全的参考方案[附录12.45]，建议参考，该方案的关键步骤如下：

6. 使用支持OAuth 2.0和OpenID Connect标准协议的授权服务器（个人建议定制自研）；

7. 使用API网关作为单一访问入口，统一实现安全治理；

8. 客户在访问微服务之前，先通过授权服务器登录获取access token，然后将access token和请求一起发送到网关；

9. 网关获取access token，通过授权服务器校验token，同时做token转换获取JWT token。

10. 网关将JWT Token和请求一起转发到后台微服务；

11. JWT中可以存储用户会话信息，该信息可以传递给后台的微服务，也可以在微服务之间传递，用作认证授权等用途；

12. 每个微服务包含JWT客户端，能够解密JWT并获取其中的用户会话信息。

13. 整个方案中，access token是一种by reference token，不包含用户信息可以直接暴露在公网上；JWT token是一种by value token，可以包含用户信息但不暴露在公网上。

• 服务部署平台选型

容器已经被社区接受为交付微服务的一种理想手段，可以实现不可变（immutable）发布模式。一个轻量级的基于容器的服务部署平台主要包括容器资源调度，发布系统，镜像治理，资源治理和IAM等模块。

1. 集群资源调度系统,目前Google开源的kubernetes已经形成市场领导者地位，github上有31.8k星,如果你的团队有足够定制自研能力，想深度把控底层调度算法，也可以基于mesos做定制自研。
2. 镜像治理,基于docker registry,vmware开源的harbor是目前社区比较成熟的企业级产品,在其基础上扩展了权限控制，审计，镜像同步，管理界面等治理能力，可以考虑采用。
3. 资源治理，目前这块还没有生产级的开源产品，一般企业需要根据自己的场景定制自研。
4. 发布平台，jenkins, Netflix开源的spinnake，但是这个产品比较复杂重量（因为它既要支持适配对接各种CI系统，同时还要适配对接各种公有云和容器云，使得整个系统异常复杂）
5. IAM:是identity & access management的简称，对发布平台各个组件进行身份认证和安全访问控制

 

此篇文章作为学习笔记，原文章链接：https://mp.weixin.qq.com/s/ENq2UlCvF0kf0P4-fUtuxA