本文已参与「新人创作礼」活动，一起开启掘金创作之路。

1. 架构演变

2. SOA架构和微服务架构

2.1 SOA架构

在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心对集群进行管理。

在SOA架构中，通常这个调度中心被称为注册中心。服务层将服务注册在注册中心，表现层只需要向注册中心索要服务地址即可，负载均衡，心跳检测等都由注册中心(SOA架构的核心)来实现。

心跳检测：或者叫服务检查，注册中心使用一定的机制定时检测已注册的服务，如果发现某个服务的集群示例长时间无法访问，就会从服务中心剔除该实例。

• 优点：

  • 使用注册中心，解决了服务间的调用关系
  • 扩展也大大增强

• 缺点：

  • 服务和服务之间有耦合，比如多个服务使用同一个数据库服务
  • 服务关系复杂，无法独立执行，部署，增加了运维和测试的难度

2.2 微服务架构

微服务架构从某种程度上来说，是对SOA架构的延伸，它强调服务的彻底拆分，即服务原子化。每一个服务都可以独立部署，独立运行，独立升级，独立扩展，有自己的数据库服务，此时的服务称为“微服务”。

现代微服务的定义：微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维

• 优点：

  • 代码复杂度低：根据业务细粒度拆分多个小服务，业务功能清晰，代码体积小，便于理解和维护。这个拆分粒度没有统一的标准，需要自己去权衡利弊。
  • 技术选型不受束缚：每个微服务可用多种不同的编程语言，可以根据自身业务选择合适的编程语言或者技术栈实现。
  • 独立部署：服务独立部署，如果修改一个后台管理服务，就只需要重新部署这个服务，其他业务不变，不仅影响范围小，也减少了部署和测试的时间。
  • 服务的可伸缩性：根据自身业务发展的实际情况，哪个服务承载量达到了上限，就多部署一些节点（集群的节点），或者是增加服务器的配置；相应的哪个服务流量小，就减少服务节点，或者降低该服务器的配置。
  • 错误隔离：在多个服务中，假如后台管理服务宕机了，但是给用户提供服务的程序正常运行，错误只会影响管理员操作后台，丝毫不影响用户的体验。
  • 分库变得更容易：微服务会拆分成多个应用，每个应用可以单独的去连接一个数据库，这样也能在一定程度上省去分库的成本，一般不再需要借助想MyCat等中间件来进行分库。

• 缺点

  • 构建微服务系统复杂：构建微服务系统并不是简单的服务调用，要充分考虑网络延迟和网络故障带来的影响。
  • 服务依赖：假设有A、B、C三个服务，A调用B，B调用C，C是最底层的服务，如果此时迫不得已要改动C的接口，可能B要改动，有可能连带A也要改动。
  • 数据一致性的问题：在微服务中，各个服务都是独立的进程，假设A服务调用B服务，在远程调用的过程中，刚好遇到网络延迟，A系统收到超时异常数据回滚，可能在B系统中已经将数据保存了。
  • 接口排除故障困难：随着服务调用链路的拉长，要定位线上问题，不得不同时查看多个服务情况。
  • 运维和部署：要检查和监控多个服务的健康状态，快速的部署多个服务，并且根据网站负载情况实现服务的动态伸缩等，都是不小的挑战。

虽然微服务有一些缺点，但很多缺点还是可以通过其他组件来弥补，另外，不要为了微服务而使用微服务，还得根据自身业务来选择。

3. 微服务所需要的技术栈

3.1 服务治理

服务治理就是进行服务的自动化管理，其核心是服务的自动注册与发现。

服务注册与发现： 当调用接口服务时，首先从服务注册与发现服务中获取被调用服务的真是地址，然后调用到某个具体的服务，调用端不必关心被调用服务的真实地址，这样就很容易实现目标服务的负载均衡，服务之间也实现了解耦。

服务剔除： 服务注册中心将出问题的服务自动剔除到可用列表之外，使其不会被调用到。

3.2 服务调用

调用端真正调用（HTTP方式等）目标服务的技术。

目前主流的远程调用技术有基于HTTP的RESTFUL接口和基于RPC协议

• REST： 这是一种HTTP的调用格式，更标准，更通用，无论哪种语言都支持http协议。
• RPC： 一种进程间的通信方式。允许像调用本地服务一样调用远程服务。RPC框架的主要作用就是让远程服务调用更简单，透明。RPC框架负责屏蔽底层的传输方式，序列化方式和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。

区别与联系：

比较项	Restful	RPC
通讯协议	HTTP	一般使用TCP
性能	略低	较高
灵活度	高	较高

3.3 服务熔断、限流、降级

保证服务的稳定性

熔断

当一个服务因为各种原因停止响应时，调用方通常会等待一段时间，然后超时或者收到错误返回。如果调用链路比较长，可能会导致请求堆积，整条链路占用大量资源一直在等待下游响应。所以当多次访问一个服务失败时，应熔断，标记该服务已停止工作，直接返回错误。直至该服务恢复正常后再重新建立连接。

服务降级

当下游服务停止工作后，如果该服务并非核心业务，则上游服务应该降级，以保证核心业务不中断。比如网上超市下单界面有一个推荐商品凑单的功能，当推荐模块挂了后，下单功能不能一起挂掉，只需要暂时关闭推荐功能即可。

限流

一个服务挂掉后，上游服务或者用户一般会习惯性地重试访问。这导致一旦服务恢复正常，很可能因为瞬间网络流量过大又立刻挂掉，在棺材里重复着仰卧起坐。因此服务需要能够自我保护——限流。限流策略有很多，最简单的比如当单位时间内请求数过多时，丢弃多余的请求。另外，也可以考虑分区限流。仅拒绝来自产生大量请求的服务的请求。例如商品服务和订单服务都需要访问促销服务，商品服务由于代码问题发起了大量请求，促销服务则只限制来自商品服务的请求，来自订单服务的请求则正常响应。

3.4 负载均衡

负载均衡算法决定调用这个集群中的哪个服务

3.5 配置中心

集中式管理项目中的配置，方便修改，解决重复配置

3.6 消息队列

服务之间可以异步、解耦，减少调用链路

3.7 服务网关

随着微服务的不断增多，不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如何让客户端直接与各个微服务通信可能出现：

1. 客户端需要调用不同的url地址，增加难度
2. 在一定的场景下，存在跨域请求的问题
3. 每个微服务都需要单独进行身份认证
4. 微服务可能使用的协议不同，客户端需要进行适配
5. 客户端需要自己实现负载均衡

....

针对这些问题，API网关顺势而生。API网关字面意思上理解，是将所有的API调用都接入到API网关，由网关层统一接入和输出。

一个网关的基本功能有：

1. 统一接入
2. 安全防护
3. 协议适配
4. 流量管控
5. 长短链接支持
6. 容错能力
7. 负载均衡

有了网关之后，各个API服务提供团队可以专注于自己的业务逻辑处理，而API网关更专注于安全，流量，路由等问题。

3.8 服务容错

在微服务当中，一个请求经常会设计调用几个服务，如果其中某个服务不可用，没有做服务容错的话，极有可能会造成一连串的服务不可用，这就是雪崩效应。

我们没法预防雪崩效应的发生，只能尽可能去做好容错。

服务容错的三个核心思想：

1. 不被外界环境影响
2. 不被上游请求压垮
3. 不被下游响应拖垮

3.9 服务监控

在高并发分布式的场景下，故障经常是突然间就雪崩式爆发。所以必须建立完善的监控体系，尽可能发现故障的征兆。

微服务架构中组件繁多，各个组件所需要监控的指标不同。比如Redis缓存一般监控占用内存值、网络流量，数据库监控连接数、磁盘空间，业务服务监控并发数、响应延迟、错误率等。

3.10 分布式链路追踪

随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发，可能使用不同的编程语言来实现，有可能部署在了几千台，上万台服务器上，横跨多个不同的数据中心。因此需要对一次请求涉及的多个服务链路进行日志记录，性能监控，这就是链路追踪。

3.11 自动化构建部署

持续集成，快速部署应用，例如使用Jenkins部署运行，或者Docker部署运行，或者Jenkins+Gitlab+Docker部署运行

4. Spring Cloud技术栈对应实现

Spring Cloud并不是一个拿来即用的框架，而是一套规范。主流的Spring Cloud Netflix和Spring Cloud Alibaba为开发者实现了这套规范，所以真正开发时使用的时Spring Cloud Netflix或Spring Cloud Alibaba的套件

技术栈即对应的落地实现：

技术栈	技术栈落地实现
服务注册与发现	Eureka、Zookeeper、Consul、Nacos
服务熔断、限流、降级	Hystrix、Resilience4j、Sentinel
服务调用	Ribbin、Loadbalancer、Feign、OpenFeign、Dubbo
配置中心	Config、Zookeeper、Consul、Nacos
服务网关	Zuul、Gateway
消息总线	Bus、Nacos

Spring Cloud是一系列框架的集合。它利用Spring Boot的开发便利性巧妙的简化了分布式系统基础设施的开发，如服务发现注册，配置中心，消息总线，负载均衡，断路器，数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。

Spring Cloud并没有重复造轮子，它只是将目前各家公司开发比较成熟的，经得起实际考验的服务框架组合起来，通过Spring Boot风格进行在封装，屏蔽掉了服务的配置和实现原理，最终给开发者留出了一套简单易懂，易部署和易维护的分布式系统开发工具包。

spring Cloud官网：spring.io/projects/sp…

而Spring Cloud Alibaba为分布式应用程序开发提供一站式解决方案。它包含开发分布式应用程序所需的所有组件，使开发者可以轻松使用Spring Cloud开发应用程序。

使用Spring Cloud Alibaba，只需要添加一些注解和少量配置，就可以将Spring Cloud程序接入Alibaba的分布式解决方案，并使用阿里巴巴中间件构建分布式应用系统。