微服务平台建设之微服务2.0技术选型思考
前言
前事不忘后事之师，本篇博客是在拜读和学习了杨波的《微服务架构技术栈选型手册》后结合自己的整理和思考。
https://www.infoq.cn/article/micro-service-technology-stack/
随着IT技术发展和推进，传统的单体应用程序模式已不满足大多数企业IT平台构建，尤其是大型互联网网站或企业级应用。单体应用随着项目持续集成，代码库越来越大，在系统复杂度、测试、代码冲突解决、可扩展性、多环境支持、需求变更容易造成系统整体影响等方面面临各种严峻挑战。此时微服务架构应运而生。
微服务从2014的1.0技术元年开始，随着微服务社区的推进，微服务技术体系生态产生极大变化，微服务进入2.0时代。微服务架构体系经过多年的大规模生产验证，已成为构建大型互联网网站、大型企业级应用的首选分布式技术架构。
相对于单体应用，微服务更具有优势：
- 易于理解：微服务将应用按照功能分解为独立开发和部署的微型应用，每个服务与应用程序的其他微服务之间有一个很小且有限的契约。微服务更加专注目标，作为一个功能模块的单元，微服务更容易理解。
- 微服务易于测试：每个微服务都是独立开发部署的微型应用，易于测试。在集成测试和验收测试方面也更易于验证。
- 较少遇到库不兼容问题：每个微服务都有自己独立的项目构建依赖项的集合，而这些集合不会与其他微服务共享。
- 微服务能够独立扩展：微服务之间独立部署，因此指定微服务的内存和实例扩展不会影响整体应用其他微服务的内存和实例数量。
- 微服务可以独立选择不同的技术栈：微服务可以选择不同的语言、平台、框架和库。特别是如果微服务采用HTTP协议这样的跨平台协议，实际上java微服务可以和C#、Python等编写的微服务协作是完全合理的。
- 微服务更易于发布：微服务是独立部署的，因此不需要等待其他微服务部署就绪。同时随着k8s、Dockers这样的容器化、自动化部署工具的出现，让微服务的发布更加简单。
微服务架构作为分布式架构，同样面临网络延迟、多服务运维、分布式复杂性等问题的挑战，如何保证微服务的构建、发布、运维管理，合理的微服务技术栈选型是重中之中。
选型准则
生产级
我们使用微服务架构是要解决实际业务场景和生产抗流量的，而不是做简单的demo，如果选择不慎可能出现生产级事故。因此，生产级（Production Ready）、可运维（Ops Ready）、可治理、技术成熟的微服务技术才是我们的首选。
使用已经在多个一线互联网或大型企业落地并经过生产挑战的
我们应该尽量选择使用已经在多个一线互联网或大型企业落地并经过生产挑战并且开源的，且在社区有良好口碑的技术栈。
开源社区活跃
社区活跃、stars数量越多、代码和文档更新频率高的技术栈是优选选择的，开源社区活跃可以直接反应技术的生命力。
结合项目实际情况
不是所有项目都适用于微服务架构体系，多余研发团队较少、应用日流量少的业务体量和企业应该慎重考虑是否使用微服务构建项目。微服务架构主要还是针对高并发、高日流量、研发团队规模较大且有独立的运维团队这样的大型业务平台或团队。同时针对团队技术能力，选择合适的微服务架构也是很有必要。
微服务基础架构关键
微服务2.0架构核心模块
微服务总体架构
微服务框架选型
微服务框架经过多年发展是一个比较成熟的领域，有比较多选择，以下为市场主流微服务架构对比：
| 功能点/微服务框架 | Spring Boot/Cloud | Dubbo/DubboXg | gRpc | Thirft | Motan |
| 功能点位 | 完整微服务框架方案 | 服务框架 | RPC | RPC | RPC |
| 是否支持REST | 是，基于Ribbon支持多种可插拔的序列化选择 | 否 | 否 | 否 | 否 |
| 是否支持RPC | 否 | 是 | 是 | 是 | 是 |
| 是否支持多语言 | 是 | 否 | 是 | 是 | 否 |
| 典型案例 | Netflix | 阿里、当当 | 谷歌 | Sina | |
| 社区活跃 | 高 | 高 | 高 | 一般 | 一般 |
| 文档丰富度 | 高 | 高 | 一般 | 一般 | 一般 |
Spring Boot/Cloud由于其Spring社区影响和Netflix的背书，以及其提供的完整一套微服务框架实现方案，目前可以认为是基于java构建微服务的标准方案。其对于新兴团队或未形成自己微服务体系的团队有较大吸引力。
Spring Boot/Cloud框架本身基于HTTP协议，是一种典型的RESTfull框架而不是RPC框架，序列化协议主要基于文本的JSON。
RESTfull天然支持跨语言平台，任何支持HTTP协议的应用都可以接入调用，但是客户端需要自己解析payload。TESTfull框架接口文档管理随着版本迭代，维护越发困难，如果没有统一标准的接口文档管理机制，更新不及时或缺乏注释等接口文档对于接口调用者和继续集成开发者来说是一个灾难。目前Spring框架也支持Swagger 契约编程模型，可以基于Swagger 契约生成各语言的强类型客户端，极大方便不同语言栈的接入。
Dubbo是阿里多年构建生产级分布式微服务的技术结晶，服务治理能力丰富，在国内社区非常活跃。Dubbo其本质是一套基于java的RPC框架。当当DubboX在Dubbo基础上进行了扩展，支持了RESTfull接口暴露的能力。
Dubbo主要面向Java技术栈，跨语言支持能力先天不足，同时由于丰富的治理能力，框架整体比较重，想要完整使用好Dubbo门槛比较高。但是如果企业基本都是基于java技术栈进行项目构建，选择Dubbo可以使项目站在比较高的起点上，Dubbo在企业级性能和服务治理能力都非常优秀。Sina的Motan和Dubbo功能类似，可以认为是Dubbo的轻量级剪裁版。
gRpc是谷歌推出的一套RPC框架，基于protobuf的强契约编程模型，能够自动生成各类语言的客户端且保证互操作。gRpc适用于内部互相调用的场景，对外暴露RESTfull API实现比较麻烦，需要引入第二套RESTfull 框架作为辅助。
运行时服务支撑服务选型
服务注册与发现
服务治理实现微服务架构体系下各个微服务实例的自动化注册和发现。大部分分布式项目在构建之初，由于微服务实例较少，基本是采用传统静态配置的方式管理服务实例清单，在项目扩展或变更时需要手工维护静态配置。随着业务发展，系统功能越来越复杂、微服务实例数量也极具增加，手工方式维护静态配置需要花费大量人力，同时还极易发生错误。服务治理组件就是为了解决微服务架构实例维护问题。
CAP原则
谈到服务注册就必须先说CAP原则，指的是分布式系统中的一致性（Consistency）、可用性（Availability）、分区容错性（Patitiontolerence），三者不可全得。
- 一致性：指的是分布式所有节点在同一时间的数据完全一致，对于一致性，一致的程度可以分为强、弱、最终一致性：
- 强一致性：对于关系数据库，要求更新数据能够被后续的访问都能看到。如A更新了V0到V1，其他线程后续读取的时候必须是V1。
- 弱一致性：能够容忍后续读取部分或者全部访问不到。如A更新V0到V1，可以容忍其他线程读取的时候仍是V0；
- 最终一致性：弱一致性的特例，保证在没有后续更新的前提下，系统经过一段时间要求返回最近一次更新后的数据。
- 可用性：分布式集群一部分节点故障后，集群整体是否还能响应客户请求。
- 分区容错：某节点故障或网络分区延迟，集群整理仍能对外提供设计好的一致性和可用性的服务。
对于分布式系统分区容错性是必定满足的，分布式架构设计主要是在AP之间进行取舍。
时下主流注册中心特点对比：
| 特点/注册服务组件 | Eureka | Zookeeper | Nacos | Cousul | etcd |
| 服务健康检查 | 可配支持 | （弱）长连接，keepalive | 可配支持 | 服务状态、内存、硬盘等 | 连接心跳 |
| 多数据中心 | 支持 | - | 支持 | 支持 | - |
| kv存储服务 | - | 支持 | - | 支持 | 支持 |
| 一致性算法 | - | paxos | Raft | raft | raft |
| CAP | AP | CP | AP、CP | CA | CP |
| 多语言支持 | http(Sidecar模式) | 客户端 | http(Sidecar模式) | 支持http和DNS | http/grpc |
| Watch支持 | 支持long polling/大部分增量 | 支持 | 支持long polling/大部分增量 | 全量/支持long polling | 支持long polling |
| 自身监控 | metrics | - | metrics | metrics | metrics |
| 安全 | - | acl | - | acl/https | https支持（弱） |
| Spring Cloud集成 | 已支持 | 已支持 | 已支持 | 已支持 | 已支持 |
如果采用的是Spring Cloud体系，那么Eureka作为服务治理组件是最佳搭配，经过了Netflix大规模生产验证，基于HTTP，支持跨数据中心，配合Feigin和Ribbon可以实现灵活的客户端软负载。在早些时候Netflix公布了停止Eureka2.X的开源工作，在国内造成很大反响，其实Spring Cloud NetFlix 使用的是Netflix 1.X稳定版本，基本对国内Spring Cloud项目不会造成影响，只是Eureka后续肯定不会有提升了，因此关注注册中心的功能及性能提升可能就需要更换社区活跃的组件了。此外Eureka相对于其他服务治理组件，Erueka需要开发者自己开发实现注册中心。Eureka注册中心集群每个节点同等，其中任意节点失效，可以立即切换到另一个节点直接使用。Eureka牺牲了数据的一致性，没有任何算法保证集群不同Server的数据一致性，仅通过数据拷贝复制保证集群Server之间的最终一致性。虽然牺牲了数据的一致性，但是提高了注册中心Server的可用性，降低了注册代价，从而提高了微服务集群运行的健壮性。
Zookeeper是应用于分布式应用程序的高性能分布式协调服务，提供了命名、配置管理、分布式锁、集群服务等功能。Zookeeper基于主从架构，Zookeeper使用Zab协议实现分布式数据的强一致性，可以用于实现强一致性的注册与发现服务，相应的Zookeeper一定程度牺牲了系统的可用性和提高了注册时间。
Nacos是Dubbo架构体系的以服务为服务对象的注册与发现、配置和管理组件，支持基于DNS和基于RPC的服务注册与发现，相对于Eureka，Nacos支持控制台和API模式的服务优雅上下线和流量控制管理。Nacos在超过1000台机器后性能比Eureka更具有优势。同时完美兼容Cloud。Nacos是Eureka 2.X不在开源后优秀的替代。
Cousul是一个服务网格（微服务间的TCP/IP，负责服务之间的网络调用、限流、熔断和监控），支持跨数据中心，提供灵活的监控检查能量和支持KV存储。
etcd是因为应用于在开源社区火热CoreOS和Kubernetes这样的项目而备受开发人员关注，etcd是基于GO语言的，基于HTTP+JSON的API机制，支持KV存储的高可用强一致性服务发现存储仓库。
服务网关
为什么需要使用API网关
传统单体应用，客户端访问服务器采用访问ip+端口+服务接口前缀，客户端程序需要维护服务实例列表，如果后续系统扩展，对于客户端开发来说是一个灾难。又如目前有些分布式架构采用F5+Nginx等设施的路由和负载，然后转发到各个不同的服务实例，此模式下需要专业运维人员进行服务实例列表清单和路由规则进行维护，当有服务实例增减和IP地址变更，运维人员需要手工更新路由规则和实例清单信息以保证实例信息和中间配置的一致性。如果系统规模不大的情况，手工维护Nginx路由规则和实例清单不算复杂，如果系统规模达到一定程度，有几十、上百、上千的服务实例需要维护，那么对于运维人员来说也是极大的挑战，同时也容易提高配置错误的概率。
单体应用服务访问IP+端口+服务前缀模式
基于Nginx进行路由配置管理
服务网关是微服务系统唯一入口，采用类似外观模式封装了系统内部架构，为客户端提供定制化API服务，同时提供登录鉴权、监控、负载均衡、请求分片与管理、静态响应处理、多协议支持、限流、熔断等高级功能。服务网关能够通过框架集成实现自动发现和管理实例，并且提供如验签、登录校验、监控等通过功能，使得微服务开发更加专注业务逻辑的实现。
服务网关模式
目前市场成熟的网关比较多，以下为比较主流的API网关对比：
| 功能/组件 | Zuul | Kong | Tyk | Traefik | Ambassador |
| 用途 | 微服务网关 | 企业级API管理 | 微服务网关 | 微服务网关 | 微服务网关 |
| 配置 | REST API/YAML静态配置 | Admin REST API/Nginx.conf | Tyk REST API | TOML | YAML |
| 前置端点类型 | 命令式 | 命令式 | 命令式 | 声明式 | 声明式 |
| 拖拽配置 | no | 支持 | no | no | no |
| 扩展功能 | 自己实现 | 插件 | 插件 | 自己实现 | 插件 |
| 服务发现 | 动态 | 动态 | 动态 | 动态 | 动态 |
| 协议 | http/https | http/https/websocket | http/https/websocket/grpc | http/https/websocket/grpc | http/https/websocket/grpc |
| ssl终止 | no | yes | yes | yes | yes |
| 限流 | 需要开发 | yes | yes | no | yes |
| 熔断 | 需要引入组件 | yes | yes | yes | no |
| 重试 | yes | yes | yes | yes | no |
| 健康检查 | yes | yes | yes | no | no |
| 负载算法 | 轮询/加权轮询/随机/自定义 | 轮询/哈希 | 轮询/加权轮询 | 轮询 | 加权轮询 |
| 社区star | 9.2K | 25.5K | 5.4K | 28.4K | 2.7K |
服务网关选择，如果是采用Spring Cloud架构，那么使用Zuul是比较好的搭配，Zuul和Spring Cloud深度集成，项目也经过Netflix大规模生产验证，支持灵活的动态过滤机制，Zuul缺点是异步性能不足，同时如果要使用高级功能需要自研或引入其他组件。
对于Spring Cloud 生态家族，Spring Cloud Gateway异军突起，其功能和Zuul网关类似，都是web网关，处理http请求，但是其支持流式编程、异步消息以及内部实现了负载、限流，扩展性更强。Gateway目前版本已发布到2.1.4 RELESE稳定性也比较好，如果使用了Spring Cloud生态，Gateway比Zuul更有优势。Gateway依赖了spring-webflux，仅适用于Spring Cloud生态。
Kong是时下比较火的服务网关，基于Nginx内核，异步性能强，同时基于lua插件机制比较灵活，社区丰富，支持熔断、负载、限流、重试等高级功能，具有丰富的插件可扩展性强。Kong具有开源和社区收费版本（社区版本功能更强大）。
配置中心选型
随着程序日益复杂，程序配置日益增加：各种功能开关、服务地址、参数配置等。在多环境的体系下，传统通过配置文件和数据库方式维护配置信息已无法满足开发人员的需求，使用配置文件维护配置信息更改配置需要重新发布程序，要实现动态加载就需要借助数据库。
目前主流配置中心主要有Spring Cloud Config、Nacos、Apollo：
| 功能/组件 | Spring Cloud Config | Apollo | Nacos |
| 配置实时推送 | 支持（Spring Cloud bus） | 支持（Http长轮询1s内） | 支持（Http长轮询1s内） |
| 版本管理 | 支持（git） | 支持 | 支持 |
| 配置回滚 | 支持（git） | 支持 | 支持 |
| 权限管理 | 支持 | 支持 | -- |
| 多集群 | 支持 | 支持 | 支持 |
| 多环境 | 支持 | 支持 | 支持 |
| 监听查询 | 支持 | 支持 | 支持 |
| 单机部署 | Config-Server+Spring Cloud + Bus + Git | Apollo + quickstart + mysql | nacos单节点 |
| 分布式部署 | Config-Server+Spring Cloud + Bus + Git + MQ（部署复杂） | Apollo + admin + portal+ mysql(部署复杂) | nacos+mysql(部署简单) |
| 配置格式校验 | 不支持 | 支持 | 支持 |
| 通信协议 | HTTP/AMQP | HTTP | HTTP |
| 数据一致性 | Git保证一致性，Config从git读取配置 | 数据库模拟消息队列，apollo定时读取 | http异步通知 |
| 性能 | 性能较低，适用于小规模场景 | 高 | 高 |
| 文档 | 详细 | 详细 | 一般 |
从上面对比可以看出三则基本能满足配置中心功能，Spring Cloud Config 是Spring Cloud生态组件，可以与Spring Cloud无缝整合，但是其性能不足以满足大规模生产级别配置中心，同时其强依赖Git使用局限性也比较大。
Apollo 是携程开源配置中心，经过携程大规模生产考验，文档齐全，读写性能高，支持页面配置，推荐Apollo作为中大规模生产级别配置中心。
Nacos是阿里配置中心，功能简单，集成和部署简单，Nacos目前不支持权限管理。
服务监控选型
服务监控主要包括日志监控、调用链监控、Metrics监控、健康检查和告警通知。
日志监控：目前日志检查标配是ELK，功能齐全，开箱即用，ElasticSearch开源社区活跃。
调用链检查：调用链检查推荐点评的CAT，CAT在多家大型互联网企业都有落地，生产特性和治理能力完善。CAT还自带告警模块。
Metrics监控依赖时间序列数据库（TSDB），目前标配组件应该是Grafana。grafana 是一款采用 go 语言编写的开源应用，主要用于大规模指标数据的可视化展现，是网络架构和应用分析中最流行的时序数据展示工具，目前已经支持绝大部分常用的时序数据库。
服务容错选型
微服务架构将系统拆分为多个独立单元，若其中某一个单元出现故障，就容易因为依赖关系而引发故障的蔓延，最终导致整个系统的崩溃，如果没有对应解决方案，这种分布式微服务架构相较于传统架构还会更加不稳定。为了解决这种问题，微服务架构系统采用了断路器模式提供保护机制，如果某个单元出现故障，通过断路器的故障监控，会向调用方返回一个错误响应而不是长时间等待。这样就不会使线程因为调用故障服务而长时间不释放，从而避免故障的蔓延。
微服务架构容错组件这块，目前Spring Cloud Hystrix 是社区标准，Spring Cloud Hystrix作为Spring Cloud 生态组件，可以无缝整合。Hystrix把熔断、限流、降级、隔离封装成了组件。任何依赖调用（数据库，服务，缓存）都可以封装在 Hystrix Command 之内，封装后自动具备容错能力。Hystrix经过了大规模的生产级验证。
后台服务技术选型
后台服务主要包括消息系统、分布式缓存、分布式数据库持久层访问、任务调度系统：
消息系统
消息中间件已是分布式架构中重要的组件，主要解决应用耦合、异步消息、流量消峰、延迟设计等问题，实现高性能、高可用、可伸缩和最终一致性架构。时下主流消息中间件主要有ActiveMQ、RabbitMQ、RocketMQ、kafaka。
| 特性/组件 | ActiveMQ | RabbitMQ | RocketMQ | kafka |
| 设计定位 | 非日志的可靠消息传输，如订单、交易、充值、流计算、消息推送等 | 和RabbitMQ类似 | 基于Zookeeperde 高性能分布式发布订阅消息系统，常规消息系统、流数据处理、监控、日志收集、处理。 | |
| 成熟度 | 成熟 | 成熟 | 中 | 日志领域成熟 |
| API完整性 | 高 | 高 | 中 | 高 |
| 多语言支持 | 支持，java优先 | 语言无关 | java | 支持，java优先 |
| 单机吞吐 | 万级 | 万级 | 千万级 | 千万级 |
| 消息延迟 | -- | 微秒 | 毫秒 | 毫秒 |
| 支持协议 | 多协议支持: OpenWire\AMQP\XMPP\REST\STOPMP |
多协议支持: AMQP\XMPP\SMTP\STOPMP |
自己定义的一套（未开源）社区提供的jms不稳定 | http |
| HA | 基于Zookeeper+LelevlDB的Master-Slave模式（主从） | Master-Slave模式，RabbitMQ服务器节点本身数据不同步，要实现HA需要使用镜像模式。镜像模式复制同步数据非常耗性能，当数据量较大时，可能产生性能瓶颈 | 分布式（主从） | 分布式（主从） |
| 数据持久 | 可以保证数据不丢失，Slave备份 | 可以保证数据不丢失，Slave备份 | 数据可靠，支持实时异步/同步刷盘，异步/同步复制 | 数据可靠，有replica机制，有灾备机制 |
| 消息推拉模式 | 多协议，pull/push均支持 | 多协议，pull/push均支持 | 多协议，pull/push均支持 | pull |
| 持久化 | 内存、文件、数据库 | 内存、文件、支持数据堆积，但是数据堆积会反向影响生产速率 | 磁盘文件 | 磁盘文件，理论上可以无限消息堆积，只要磁盘容量足够 |
| 事务消息 | 支持 | 支持，性能较弱，主要还是使用Confirm发送方消息确认方式保证一致性 | 支持 | 支持 |
| 负载均衡 | 支持 | 支持 | 支持 | |
| 管理界面 | 一般 | 较好 | 命令行界面 | 命令行界面 |
| 最新版本 | 3.8.3 | 2.5 | ||
| 身份验证 | 支持OAuth 2.0 | 无 | 无 | |
| 队列特性 | -- | 死信/延迟/优先级/仲裁队列 | 支持 | 不支持 |
| 多租户 | -- | 支持 | -- | -- |
| 流量控制 | -- | 支持 | 支持 | 支持 |
| 消息追踪 | -- | 支持 | -- | 不支持 |
| 消息过滤 | -- | 不支持，可以通过二次封装实现 | 支持 | 客户端级别支持 |
| 社区活跃 | 一般 | 高 | 中 | 高 |
| 优点 | 成品成熟，功能完备、多协议支持比较好，有多重语言的成熟客户端。 |
|
|
|
| 缺点 | 不适用于上千队列以上场景使用，团队重新转移到apollo，社区不大活跃。 |
|
|
|
对于非日志可靠消息场景，就是在RocketMQ和RabbitMQ两者中间选择，RabbitMQ由于其高性能、功能完备、完善的admin管理一直是中小型企业以及吞吐量要求不高场景的首选方案。而对于吞吐量、并发要求高的一线互联网企业基本优先考虑RocketMQ。而kafka对于日志采集和传输这样的对消息可靠性要求不高的高吞吐、高并发场景一直是行业基准。kafka非常适用于吞吐量特别高、并发量特别大只是收发消息的场景。
缓存治理
对于缓存治理，对于中小规模单机模式或主备模式的小规模应用redis场景，需求并不强烈，缓存治理的性价比不高。如果Redis-Sentinel、Redis-Cluster大规模集群，如果单纯依靠运维手工维护，维护成本高且容易出错。并且手工模式维护对于缓存监控、统计、管理方面也不完善，无法合理利用集群资源。因此在大规模缓存集群场景缓存自动化治理工具的价值就体现出来了。
如果项目采用的是redis客户端直连模式，则shouhu开源的CacheCloud redis云管理平台是不错选择。CacheCloud实现多类型redis部署模式（Redis Standalone、Redis Sentinel、Redis Cluster）自动化部署，自动故障转移、监控、统计、自动化运维等生产治理功能，同时社区文档丰富。
如果倾向选择中间层代理实现redis集群，这推特的Twemproxy和豌豆荚的Codis是比较好的选择。Twemproxy是一种代理分片机制，Twemproxy作为代理服务器接受多个程序的访问，根据路由规则将访问请求转发给后台redis服务器，然后原路返回。Twemproxy将redis集群服务器统一管理，是的客户端程序无需维护多个redis实例连接；Twemproxy连接方式和redis 客户端链接一样，无需修改程序代码。Twemproxy无法平滑的扩展或缩减redis实例，缺少友好的监控界面，不利于运维，同时因为所有访问都要过Twemproxy服务器，可能会造成一定性能损失。Codis和Twemproxy功能类似，也是代理分片机制，Codis相对于Twemproxy最大优势是解决了Twemproxy无法水平平滑扩展问题。
另外，也可以使用云Redis，程序只需要维护云redis服务器地址，无需关心负载、扩容、灾备。
分布式数据访问层
分布式数据库f访问通常分为三条路线：分布式访问客户端、分布式访问中间件模式（Proxy）、分布式数据库模式。如果是分布式访问客户端模式，则推荐ShardingSphere（Sharding-JDBC），ShardingSphere是当当开源分布式数据库中间件解决方案，基于java语言实现，提供数据分片、分布式事务、数据库治理等功能。ShardingSphere体系成员包含Sharding-JDBC、Sharding-Proxy。Sharding-JDBC为轻量级java框架，在java JDBC层提供额外的服务，以jar形式提供服务，无需额外部署和依赖。通过对JDBC的封装，兼容JDBC和支持任何ORM框架。ShardingSphere于2020.4.16孵化毕业。分布式访问客户端模式比较简单和轻量，适应中小型业务场景。
如果是分布式访问中间件模式（Proxy），主要区分为重量级中间件：商业形态（阿里云DRDS、腾讯云DCDB）、开源形态（MyCat、Cobar）和轻量级中间件ShardingSphere（Sharding-JDBC）、proxysql。如果是使用中间件模式（Proxy）需要花费较高运维成本，且团队需要一定自研和运维能力，中间件模式（Proxy）适应于中大规模场景。
任务调度系统
任务调度领域技术比较成熟，可以自研和使用开源产品。开源产品推荐点评徐雪里xxl-job和当当的elastic-job。xxl-job和elastic-job社区都比较活跃、文档齐全、有几十家登记落地企业。xxl-job 轻量级分布式调度框架，使用自研调度基于mysql集群实现HA，xxl-job文档丰富，学习和实现简单，容易扩展。xxl-job基于mysql集群实现HA，在服务器较多情况，会对数据库带来一定压力，适应于服务器在一定范围场景。elastic-job基于ZK实现HA，关注的是数据，增加了弹性扩容和数据分片的思路，以便于更大限度的利用分布式服务器的资源。但是elastic-job学习成本和部署成本相对高些，推荐在数据量庞大，且部署服务器数量较多时使用。xxl-job和elastic-job对比。
服务安全选型
目前绝大多数项目都是多端+前后端分离，传统基于Session认证的前后端放到一起的项目逐渐失宠。目前主流的安全认证方案是基于Token的用户认证。目前主流开源认证框架有Apache Shiro和Spring Security，项目可以选择开源安全框架也可以基于 OAuth 和 OpenID connect 标准，自研定制化轻量级授权服务。WSO2提供了微服务安全认证方案：
- 使用支持OAuth 2.0和 OpenID connect标准协议的授权服务器；
- 使用api网关作为统一入口，统一实现安全治理；
- 客户端在访问微服务前，先从授权服务器获取access token，然后将access token和访问请求一起发送到网关；
- 网关获取access token，通过授权服务器校验token，同时做token转JWT(JSON Web Token) token；
- 网关将JWT 和请求转发到后台微服务；
- JWT可以存储用户会话信息，该信息可以传递给微服务，也可以在微服务间传递，用作用户认证授权等操作；
- 每个微服务都包含一个JWT客户端，可以解密JWT获取其中用户会话信息；
- 整个方案中access token是一种by reference token，不包含用户信息可以暴露在公网上，JWT token是一种 by value token，包含用户信息，不暴露在公网（微服务JWT边界安全机制）
jwt 微服务安全方案
持续集成服务（CI）选型
持续集成服务（CI）是保证服务快速开发、代码质量控制、产品快速迭代的重要流程，同时CI也能解放大量传统代码交互运维工作，实现代码自动化管理。持续集成服务（CI）服务器是比较成熟领域，市场有多款商业或开源服务器。这里主要说下Git + Docker + Bamboo + k8s 实现持续集成架构。Bamboo是商业（价格比较友好，基本所有团队都能够承受）的企业级的
CI持续集成工具，具有灵活的权限管理、友好操作界面、开箱即用、操作简单，支持Docker、AWS CodeDeploy等热门技术。Bamboo 相对于其他CI工具最大的优势是与Jira SoftWare、Bitbucket的最佳集成，实现了项目从计划到最终交付的全流程管理。
服务部署平台选型
容器已经成为微服务交互的理想手段，可以实现不可变（Immutale）发布模式。一个轻量级的基于容器的部署平台主要包含资源调度、发布系统、镜像治理、资源治理和IAM等模块。
集群资源调度系统：屏蔽容器细节，将整个集群抽象为容器池，支持按需申请和释放容器资源，物理机发生故障时能够实现自动故障转移（fail over）。目前Google开源的Kubernetes凭借Google背书和活跃社区的强力推动，基本形成市场领导地位。容器资源调度首选K8S。如果项目组有足够自研能力，想深度控制调度算法，也能可以基于Mesos 进行容器调度自研。
镜像治理：基于Docker Register，封装一些轻量级治理功能。VMware 开源的harbor是比较成熟的企业级产品，在Docker Register基础上扩展了权限控制、申请、镜像同步、管理界面等治理能力。
资源治理：对应用APP、组织org、容器配额和数量等进行管理。
发布平台：面向用户的发布管理控制台，支持发布流程编排。它和其它子系统对接交互，实现基本的应用发布能力，也实现如蓝绿，金丝雀和灰度等高级发布机制。
IAM：是 identity & access management 的简称，对发布平台各个组件进行身份认证和安全访问控制。