微服务架构技术栈

经过多年的发展，微服务已经成为了企业主流的架构首选，今天我们重新盘点一下微服务架构的技术栈，探讨微服务学习的全路径。

什么是微服务

维基百科定义：

微服务（Microservices）是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关的API集相互通信。

2014年，Martin Fowler与 James Lewis共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用HTTP API通信。同时服务会使用最小的规模的集中管理 (例如Docker) 能力，服务可以用不同的编程语言与数据库等组件实现。

微服务的优势与劣势

优势：

1. 应用小，可快速编译部署

2. 单个微服务维护性变高，修改容易，因为每个团队独立负责一块功能，新功能交付变快，可以快速开发交付。

3. 扩展性变高，根据业务规模可以随时缩减/增加服务器规模

4. 可靠性变强，可以部署很多独立的服务

5. 业务解耦，按照业务边界拆分为多个独立的服务模块

6. 提升研发效率，业务拆分后，服务模块变小，在一个团队内就可以独立编写、测试、发布，加快研发效率。

劣势：

1. 整体架构复杂度变高：微服务怎么划分，如何确定边界？多“微”才是好的“微”？

2. 运维复杂：微服务变多，怎么监控所有微服务，保证服务稳定？出了问题，怎么定位问题？

3. 服务管理：微服务变多，管理复杂度变高，治理变得复杂

4. 测试复杂：如何集成测试？

5. 分布式问题：分布式数据一致性、分布式事务

6. 服务保障：一个服务出了问题，如何才能不影响其他服务？

微服务不是银弹，它带来了很多优势，同时也带来了很多劣势。

微服务架构是为了适应业务的快速变化，产品的快速迭代、交付、反馈和修改，团队成员膨胀而提出的一种架构解决方案。

微服务架构图

上面的技术架构图一共分了6层

1. 接入层

也叫负载均衡层，把外部的流量引入到系统中来。一般负载均衡软件有nginx，lvs，还有各大云服务厂商自己的负载均衡服务。

2. 网关层

内部接口的认证、安全、鉴权、过滤、限流等服务。网关把内部的服务接口做一层安全隔离，保护内部服务，同时也可以实现一些其他需求，比如鉴权、黑名单过滤等。

3. 业务层

基础服务和聚合服务

• 基础服务：根据业务特点又可以分为核心基础服务、公共服务、中间层服务等。

• 聚合服务：把下面细粒度的基础服务再进一步封装、关联，组合成新的服务，供上层调用。这一层可以实现多变的需求。 

上面的这种划分是根据逻辑来划分，各个公司可以根据自己实际的业务需求来进行划分。

4. 支撑服务层

微服务能够成功实施落地，这一层与下一层CI/CD的配套设施是非常重要。微服务不是把上面的业务服务写完就完事了，在服务治理的过程中需要很多配套设置支持，包括注册服务中心，配置中心，监控报警服务，日志聚合服务，调用链监控几大服务，后台服务涉及的服务有消息队列，定时任务，数据访问等。

5. 平台服务层

这一层是实施业务弹性治理的关键。集群的资源调度：扩展和减少。业务量上来时，可以弹性增加资源。  在微服务建设过程中，可能会遇到一些突发事件。比如微博明星热点事件，会导致访问量暴增，这就需要能实时增加服务资源应对这种突发情况，热点过后，又要减少资源。  镜像管理和发布系统配合使用可以应对出现的这种情况。所以很多团队后面会引入docker+k8s，容器，镜像管理，容器服务编排。此外，基于CI/CD的DevOps也是构建在这一层能力。

6. 基础设施层

最底层的基础设施，也就是常说的IAAS层，主要包括计算机的计算，网络，存储，硬盘，安全等

上图橙色标注的模块是和微服务开发人员关系最密切的模块，常规的系统开发都是围绕这部分展开。

JAVA微服务技术栈

下面我们重点说明下相关的微服务核心关键技术栈，本文讨论的基于JAVA开发。

服务框架

用JAVA技术开发微服务，比较主流的选择有：Spring Cloud 和 Dubbo。

Spring Cloud是在Spring基础上构建的，它后面有2大公司支撑，Pivotal和Netflix的技术支持。它的核心就是Netflix贡献的源码，目前可以认为是构建 Java 微服务的一个社区标准。

Dubbo 是阿里多年构建生产级分布式微服务的技术结晶，服务治理能力非常丰富，在国内技术社区具有很大影响力，Dubbo 本质上是一套基于 Java 的 RPC 框架。

此外还有：

当当的Dubbox，Dubbox在Dubbo的基础上拓展了RESTful的接口暴露能力。

新浪微博的Motan，功能和Dubbo类似，可以认为是一个轻量裁剪版的Dubbo。

谷歌的gPRC，是谷歌近年新推出的RPC框架，基于protobuf的强契约编程模型，能自动生成各种语言客户端，且保证互操作。

服务网关

如果采用Spring Cloud体系，则可以选择Zuul网关，Zuul在Netflix经过大规模生产验证，支持灵活的动态过滤器脚本机制。

此外还有：

Spring Cloud Gateway，Spring Cloud新推出的网关框架；

基于 Nginx/OpenResty 的 API 网关 Kong，因为采用 Nginx 内核，Kong 的异步性能较强，另外基于 lua 的插件机制比较灵活，社区插件也比较丰富。

服务治理

• 服务注册和发现：Netflix Eureka，支持跨数据中心，除此之外，还有Consul（天然支持跨数据中心，还支持 KV 模型存储和灵活健康检查能力），Zookeeper等

• 断路器：Hystrix，Netflix 的Hystrix把熔断、隔离、限流和降级等能力封装成组件，任何依赖调用（数据库，服务，缓存）都可以封装在Hystrix Command之内，封装后自动具备容错能力。除此之外，Netflix的Hystri停更后，SpringCloud家族推荐Resilience4j，另外阿里也推出了Sentinel。

• 调用端负载均衡：Ribbon

• REST客户端：Feign

• 分布式事务：阿里开源的Seata，个人开源 TX-LCN

• 消息队列：Spring Cloud的Spring Cloud Bus和Spring Cloud Stream，阿里开源的RocketMQ，Linkedin开源的Kafka

配置中心

• Spring Cloud 自带 Spring Cloud Config

• 携程开源的Apollo，在携程经过生产级验证，具备高可用，配置实时生效（推拉结合），配置审计和版本化，多环境多集群支持等生产级特性，建议中大规模需要对配置集中进行治理的企业采用。

• 阿里开源的Nacos，Nacos集注册发现和配置中心于一体。

服务监控

主要包括日志监控，调用链监控，Metrics 监控，健康检查和告警通知等产品。

ELK 目前可以认为是日志监控的标配

调用链监控目前社区主流是点评 CAT，Twitter开源的Zipkin，Naver开源的Pinpoint，还有国内开源的Skywalking等

其他服务

• 分布式缓存：Redis

• 分布式数据库访问层：MyCat

• 任务调度系统：徐雪里开源的 xxl-job，阿里开源的Alibaba Cloud SchedulerX

持续集成

持续交付流水线（CD Pipeline）是微服务发布重要环节，包括基于Docker的镜像治理、基于Kubernetes的集群资源调度，以及资源治理和发布平台等。

下图为可供参考的流水线模型：

总结

微服务是一个庞大的架构体系，每个企业的具体上下文（业务场景，团队组织，技术架构等）各不相同，所以技术选型存在多种多样，没有最好的技术栈，只有相对较合适的技术栈。而且技术栈仅是微服务建设的一小部分工作，产品落地才是建设目的，而且系统落地后还有大量集成、定制、治理、运维和推广等工作，微服务不是银弹。