学习、跳槽涨薪？请关注

随着业务的不断发展, 用户体量的快速扩张. 从单体/垂直架构转移到分布式/微服务架构是自然而然的选择.

01 分布式理论

分布式理论是分布式系统的基础, 在任何情况下分布式系统都要满足网络分区容错性, 因此分布式系统都是在可用性和一致性方面做平衡.

02 CAP理论

CAP理论指的是在一个分布式系统中,一致性、 可用性、分区容错性、在任何情况下只能满足其中两个,三个不能同时满足.

三个特性含义如下:

• Consistency(一致性) 指数据在多个副本之间能够保持一致的特性(严格的一致性)。
• Availability(可用性) 指系统提供的服务必须一直处于可用的状态，每次请求都能获取到非错的响应(不保证获取的数据为最新数据)。
• Partition tolerance(分区容错性) 分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环- 境都发生了故障。

CAP原理告诉我们，C,A,P三个方面同时只能满足两个，不可能同时满足。然而对于分布式系统而言，分区容错性[P]是基本要求,系统根据自身方面的要求需要对可用性和一致性做取舍.

对于网站服务来说, 可用性可能价值更高, 所以一般网站都会选择作为可用性放弃一致性. 而对于数据库系统, 数据一致性是重中之重, 所以数据库系统追求的是一致性放弃的是可用性.

03 BASE理论

BASE的核心思想是：

既然无法做到强一致性，然而每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

BASE理论的三个要点为:

• 基本可用(Basically Available)当系统出现故障时,损失部分功能的前提下保障系统基本功能的可用性，相比较正常的系统而言, 可能是响应时间的增大, 亦或者是功能的降级, 如电商系统大促秒杀期间为保障系统稳定导致部分服务接口降级.
• 软状态(Soft State)软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。相对于原的性的强一致硬状态而言，我们称之为软状态。
• 最终一致性(Eventually Consistent)软状态不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素。

04 微服务的优势

• 降低复杂度将原来偶合在一起的复杂业务拆分为单个服务，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。每个服务开发者只专注服务本身，通过使用缓存、DAL等各种技术手段来提升系统的性能，而对于消费方来说完全透明。
• 可独立部署由于微服务具备独立的运行进程，所以每个微服务可以独立部署。当业务迭代时只需要发布相关服务的迭代即可，降低了测试的工作量同时也降低了服务发布的风险。
• 容错在微服务架构下，当某一组件发生故障时，故障会被隔离在单个服务中。通过限流、熔断等方式降低错误导致的危害，保障核心业务正常运行。
• 扩展单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。

05 微服务的设计要点

• 服务的拆分和粒度服务通用的拆分原则是按业务线的垂直拆分和功能上的水平划分. 至于服务拆分到的粒度则是仁者见仁智者见智, 粒度粗细取决的方面有很多,如业务团队、部署运维、访问流量及硬件资源的限制等.
• 服务接口去状态化根据cap理论, 只要涉及状态涉及到数据一致性问题, 在分布式环境下保证一致性就要以牺牲可用性为前提.因此状态是影响服务水平扩展的根本原因, 一个无状态的服务理论上可以随意的迁移和扩展. 然而应用的状态是不可避免的,比如用户订单、登录状态等等.我们的原则是将整个业务分成两部分, 无状态的服务和有状态的存储. 服务接口作为计算单元处理用户的请求,根据用户的访问量按需水平扩展,而状态部分则交给专门的数据存储集群来处理,如Redis,数据库等. 内存中不应该保存状态信息.
• 重试及幂等性分布式的复杂性在于引入了网络的复杂性, 网络操作存在未知情况. 比如系统之间相互调用时网络超时、丢包、网络分区等等，导致未成功处理或者处理成功未成功接收到响应等情况. 此时常用的手段是重试机制. 重试要求操作具有幂等性.
• 数据库扩展及分布式事务数据库是常用保存状态的地方,也是最容易出现瓶颈的地方. 根据cap理论, 传统数据库由于数据库一致性要求很难进行水平扩展. 然而有了分布式数据库可以使数据库的性能可以随着节点增加线性地增加。在微服务领域分布式事务是一个绕不开的话题, 在单体架构时期, 数据库本地事务保证了数据的一致性. 在微服务架构中, 由于服务功能的拆分,原本的事务操作可能要跨多个服务, 此时为了保证数据的一致性引入了分布式事务.分布式事务的处理方式分两种:强一致性和最终一致性(BASE).
• 数据缓存在高并发场景下缓存是非常重要的。有层次的使用缓存能有效减轻系统的压力. 要有层次的使用多级缓存, 缓存数据尽量靠近用户. 比如在web端有一层静态数据缓存、通过cdn，将静态数据放到距离客户较近的地方下载，数据库之上增加redis缓存,动态数据的静态化等等.
• 服务注册发现微服务架构服务之间有较强的依赖, 服务之间相互调用必须是动态灵活的. 当服务前移或增加实例时系统能够动态发现.
  常用的发现机制有: 基于注册中心的注册发现机制和基于dns的动态解析机制.
• 统一配置中心一类是几乎不变的配置，这种配置可以直接打在容器镜像里面
  第二类是启动时就会确定的配置，这种配置往往通过环境变量，在容器启动的时候传进去
  第三类就是统一的配置，需要通过配置中心进行下发
• 熔断，限流，降级服务要有熔断，限流，降级的能力，当一个服务调用另一个服务，出现超时的时候，应及时返回，而非阻塞在那个地方，从而影响其他用户的交易，可以返回默认的托底数据。
• 全方位的监控当系统非常复杂的时候，要有统一的监控，主要有两个方面，一个是是否健康，一个是性能瓶颈在哪里。

06 微服务框架

当前开源的微服务框架有Dubbo, Spring Cloud, Dubbox, Thrift, GRPC等;以Dubbo和Spring Cloud使用最广,以下对两个框架进行比较。

• DubboDubbo采用Zookeeper作为注册中心，RPC作为服务调用方式，致力于提供高性能和透明化的RPC远程服务调用方案。它与Spring无缝集成，基于服务提供方(服务端)与服务调用方(客户端)角色构建简单模型，其优点是使用方便、学习成本低。虽然Dubbo 支持短连接大数据量的服务提供模式，但绝大多数情况下都是使用长连接小数据量的模式提供服务使用的。所以，对于类似于电商等同步调用场景多并且能支撑搭建Dubbo 这套比较复杂环境的成本的产品而言，Dubbo 确实是一个可以考虑的选择。但如果产品业务中由于后台业务逻辑复杂、时间长而导致异步逻辑比较多的话，可能Dubbo 并不合适。
• Spring CloudSpring Cloud由众多子项目组成，如Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Consul 等，提供了搭建分布式系统及微服务常用的工具，如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性token、全局锁、选主、分布式会话和集群状态等，满足了构建微服务所需的所有解决方案。比如使用Spring Cloud Config 可以实现统一配置中心，对配置进行统一管理；使用Spring Cloud Netflix 可以实现Netflix 组件的功能 - 服务发现(Eureka)、智能路由(Zuul)、客户端负载均衡(Ribbon)。

Dubbo & Spring Cloud对比

• dubbo只实现服务治理的核心部分, 而配置管理、api网关、服务跟踪等功能则需要自己实现. 而Spring Cloud子项目分别覆盖了微服务架构的方方面面，提供了一整套开箱即用的工具包.
• Dubbo默认采用Dubbo协议，Dubbo协议工作在TCP层,同等条件下性能优于HTTP协议,Spring Clould采用HTTP协议, 性能略逊于Dubbo.
• Dubbo缺省协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用.
• spring cloud使用Ribbon作为负载均衡的组件，Ribbon需要进行全局配置，个性化配置比较麻烦。Dubbo 可以使用路由策略，然后再进行负载均衡。
• Spring cloud 的 Hystix 提供了服务降级，服务熔断，依赖隔离.Dubbo 提供了一整套 FailOver、FailFast、Failsafe、FailBack、Aviailable、Broadcast、Forking 策略.