浅析分布式架构和微服务架构

分布式架构

在《分布式系统原理与范型》一书中有如下定义：

“分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统”；

分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储等任务。其目的是利用更多的机器，处理更多的数据。

分布式系统（distributed system）是建立在网络之上的软件系统。

首先需要明确的是，只有当单个节点的处理能力无法满足日益增长的计算、存储任务的时候，且硬件的提升（加内存、加磁盘、提升CPU核数）无法明显改善时，应用程序也无法进一步优化的场景，我们才需要考虑分布式系统。因为，分布式系统要解决的问题本身是和单机系统一样的，而由于分布式系统多节点、通过网络通信的拓扑结构，会引入很多单机系统没有的问题，为了解决这些问题又会引入更多的机制、协议，带来更多的问题。

因此，随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，急需一个治理系统确保架构有条不紊的演进。

分布式的典型代表：Dubbo。当然了，Dubbo现在也提供了微服务的生态。

微服务架构

任何技术的演进都是有迹可循的，任何新技术的出现都是为了解决原有技术无法解决的需求，所以，微服务的出现就是因为原来单体应用架构已经无法满足当前互联网产品的技术需求。微服务的设计就是为了解决不因为某个模块的升级和BUG影响整体的系统业务。

微服务架构，核心就是为了解决应用微服务化之后的服务治理问题。

在微服务架构之前还有一个概念：SOA（Service-Oriented Architecture）– 面向服务的体系架构。

微服务的特征：

单一职责的。一个微服务应该都是单一职责的，这才是“微”的体现，一个微服务解决一个业务问题（注意是一个业务问题而不是一个接口）。
面向服务的。将自己的业务能力封装并对外提供服务，这是继承SOA的核心思想，一个微服务本身也可能使用到其它微服务的能力。

应用微服务化之后，会出现一些问题：

  • 服务发现问题。一个微服务如何发现其他微服务呢？最简单的方式就是每个微服务里面配置其他微服务的地址，但是当微服务数量众多的时候，这样做明显不现实。所以需要使用到微服务架构中的一个最重要的组件：服务注册中心，所有服务都注册到服务注册中心，同时利用服务发现机制可以从服务注册中心获取当前可用的服务清单。
  • 服务配置管理的问题。当服务数量超过一定程度之后，如果需要在每个服务里面分别维护每一个服务的配置文件，运维人员估计要哭了。那么，就需要用到微服务架构里面第二个重要的组件：配置中心。
  • 服务治理问题，当客户端或外部应用调用服务的时候怎么处理呢？服务A可能有多个节点，服务A、服务B和服务C的服务地址都不同，服务授权验证在哪里做？这时，就需要使用到服务网关提供统一的服务入口，最终形成典型微服务架构：

这便是一个典型的微服务架构，当然微服务的服务治理还涉及很多内容，比如：

  • 通过熔断、限流等机制保证高可用；
  • 微服务之间调用的负载均衡；
  • 分布式事务（2PC、3PC、TCC、LCN等）；
  • 服务调用链跟踪等等。

服务治理主要作用是改变运行时服务的行为和选址逻辑、限流熔断、负载权重、配置读写、日志追踪等目的。

分布式和微服务的区别

分布式和微服的架构很相似，只是部署的方式不一样而已。分布式服务架构与微服务架构概念的区别与联系：

分布式 – 分散压力

  • 不同模块部署在不同服务器上;
    • 作用：分布式解决网站高并发带来性能问题；
  • 集群：相同的服务；
    • 多台服务器部署相同应用构成一个集群；
    • 作用：通过负载均衡设备共同对外提供服务；
  • SOA［组装服务/ESB企业服务总线］;
    • 业务系统分解为多个组件，让每个组件都独立提供离散，自治，可复用的服务能力;
    • 通过服务的组合和编排来实现上层的业务流程;
    • 作用：简化维护，降低整体风险，伸缩灵活;

微服务 – 分散能力

  • 架构设计概念：各服务间隔离（分布式也是隔离），自治（分布式依赖整体组合），其它特性（单一职责，边界，异步通信，独立部署），是分布式概念更加严格的执行;
  • 作用：各服务可独立应用，组合服务也可系统应用（巨石应用［monolith］的简化实现策略 – 平台思想）.

将所有功能都部署在一个web容器中运行的系统就叫做巨石应用。

核心：分布式重在资源共享与加快计算机计算速度。 分布式:分散压力。微服务:分散能力。

问题：分布式是否属于微服务？

关于这个问题，搜罗了蛮多博文，答案也不完全一致，有属于也有不属于。

个人理解：如果不对微服务的’微’字太较真，或者分布式节点上部署的应用业务粒度足够小，那可以认为分布式属于微服务。

但是反过来就不成立了。因为微服务就是将业务模块拆分成一个独立的服务单元，然后基于网络通信通过接口来实现数据的交互，微服务不一定是分布式，因为微服务的应用不一定是分散在多个服务器上，它可以是同一个服务器。这也是分布式和微服务的一个细微差别。

微服务架构的理解

在应用的初始阶段，单体架构无论是在开发速度、运维难度上，还是服务器的成本上都有着显著的优势。在一个产品的前景不明确的初始阶段，使用单体架构是非常明智的选择。随着应用业务的发展和业务复杂度的提高，这种架构明显存在很多的不足，主要体现在以下 3 个方面:

  1. 业务越来越复杂，单体应用的代码量越来越大，代码的可读性、可维护性和可扩展性下降， 新人接手代码所需的时间成倍增加，业务扩展带来的代价越来越大。
  2. 随着用户越来越多，程序承受的并发越来越高，单体应用的并发能力有限。
  3. 测试的难度越来越大，单体应用的业务都在同个程序中，随着业务的扩张、复杂度的增加， 单体应用修改业务或者增加业务或许会给其他业务带来定的影响，导致测试难度增加。

微服务（不是一个框架 而是一种架构思想），是著名的 oo （面向对象， Object Oriented ）专家 Martin Fowler 提出来的，它是用来描述将软件应用程序设计为独立部署的服务的种特殊方式。微服务架将业务整体构按领域划分为独立的服务单元，有自动化运维、容错、快速演进的特点，它能够解决传统单体架构系统的痛点，同时也能满足越来越复杂的业务需求。

Martin Fowler 对微服务的理解：

简而言之，微服务架构的风格，就是将单一程序开发成一个微服务， 每个微服务运行在自己的进程中，并使用轻量级通信机制，通常是 HTTP RESTFUL API 。这些服务围绕业务能力来划分构建的，并通过完全自动化部署机制来独立部署这些服务可以使用不同的编程语言，以及不同数据存储技术，以保证最低限度的集中式管理。

微服务的特点

微服务单元基于业务划分

微服务的“微”到底需要定义到什么样的程度，这是个非常难以界定的概念，可以从几个方面来界定:

  • 是根据代码量来定义，根据代码的多少来判断程序的大小:
  • 是根据开发时间的长短来判断；
  • 是根据业务粒度的大小来划分；

根据 Martin Fowler 的定义，微服务的“微”是按照业务来划分的 。一个大的业务可以拆分成若干小的业务， 小的业务又可以拆分成若干更小的业务，业务到底怎么拆分才算合适，这需要开发人员根据领域划分和职责划分自己去决定。

微服务基于HTTP协议进行通信

按照业务划分的微服务单元独立部署并运行在各自的进程中。微服务单元之间的通信方般倾向于使用 HTTP 这种简单的通信机制，更多的时候是使用 RESTfulAPI 。这种接受请求、处理业务逻辑、返回数据的 HTTP 模式非常高效，并且这种通机制与平台和语言无关。

微服务的数据库独立

在单体架构中，所有的业务都共用一个数据库。随着业务量的增加，数据库的表的数量越来越多，难以管理和维护，并且数据量的增加会导致数据库服务器压力越来越大，查询速度越来越慢。 微服务的特点就是按业务划分服务，服务与服务之间无耦合，就数据库也是独立的，典型的微服务架构就是每个微服务都有自己独立的数据库，数据库之间没有何联系，这样做的好处在于随着业务的不断扩张，服务与服务之间不需要提供数据库集成，而是提供 API 接口相互调用，还有个好处是数据库独立，单业务的数据量少，易于维护，数据库性能有着明显的优势，数据库的迁移也很方便。

微服务的自动化部署(CI /CD)(持续集成 持续交付)

在微服务架构中，系统会被拆分为若干个微服务，每个微服务又是一个独立的应用程序。单体架构的应用程序只需要部署一次，而微服务架构有多少个服务就需要部署多少次。随着服务数量的增加，如果微服务按照单体架构的部署方式，部署的难度会呈指数增加。业务的粒度划分得越细，微服务的数量就越多，这时需要更稳定的部署机制。随着技术的发展，尤其是 Docker 容器技术的推进，以及自动化部署工具（例如开源组件 Jenkins）的出现，微服务的自动化部署(CI持续集成 /CD持续交付)变得越来越简单。 自动化部署可以提高部署的效率，减少人为的控制，部署过程中出现错误的概率降低，部署过程的每一步自动化，提高软件的质量。构建一个自动化部署的系统，虽然在前期需要开发人员或者运维人员的学习，但对于整个软件系统来说是一个全新的概念。在软件系统的整个生命周期之中，每一步是由程序控制的，而不是人为控制，软件的质量提高到了一个新的高度。随着 DevOps 这种全新概念的推进，自动化部署必然会成为微服务部署的优配方式。

微服务的集中化管理

微服务系统是按业务单元来划分服务的，服务数量越多，管理起来就越复杂，因此微服务必须使用集中化管理。目前流行的微服务框架中，例如： Spring Cloud 采用 Eureka、Nacos 等来进行注册服务和服务发现，另外， Zookeeper、 Consul 等业都是非常优秀的服务集中化管理框架。只不过基于CAP理论，这个开源框架的侧重点不同，开发者可以视业务场景选择合适的框架。

熔断机制

为了防止“雪崩效应”事件的发生，分布式系统采用了熔断机制。在用 SpringCloud 构建的微服务系统中，采用了熔断器（即 Hystrix 组件的 Circuit Breaker）去做熔断。

微服务的优劣势

微服务的优势

相对于单体服务来说，微服务具有很多的优势，主要体现在以下方面。

  1. 将一个复杂的业务分解成若干小的业务，每个业务拆分成一个服务，服务的边界明确，将复杂的问题简单化。服务按照业务拆分，代码也是按照业务来拆分，代码的可读性和可扩展性增加。
  2. 服务与服务之间没有耦合，随着业务的增加，可以根据业务再拆分服务，具有极强的横向扩展能力。随着应用的用户量的增加，井发量增加，可以将微服务集群化部署，从而增加系统的负载能力。简而言之，微服务系统的微服务单元具有很强的横向扩展能力。
  3. 服务与服务通过HTT网络通信协议来交互，单个微服务内部高度内聚，服务与服务之间完全独立，无耦合。这使得微服务可以采用任何的开发语言和技术来实现。开发人员不再被强迫使用公司以前的技术或者已经过时的技术，而是可以自由选择最适合业务场景的或者最适合自己的开发语言和技术，提高开发效率、降低开发成本。
  4. 如果是一个单体的应用，由于业务的复杂性、代码的耦合性，以及可能存在的历史问题。 在重写一个单体应用时，要求重写的应用的人员了解所有的业务，所以重写单体应用是非常困难的，并且重写风险也较高。如果是微服务系统，由于微服务系统是按照业务的进行拆分的，并且有坚实的服务边界，所以重写某个服务就相当于重写某一个业务的代码。
  5. 微服务在 CAP 理论中采用的是 AP 架构，即具有高可用和分区容错的特点。高可用主要体现在系统 7 x 24 小时不间断的服务，它要求系统有大量的服务器集群，从而提高了系统 的负载能力。另外，分区容错也使得系统更加健壮。

微服务的不足

凡事都有两面性，微服务也不例外，微服务相对于单体应用来说具有很多的优势，当然也有它 的不足，主要体现在如下方面:

  1. 微服务的复杂度
  2. 分布式事务问题。
  3. 服务的划分（按照功能划分还是按照组件来划分呢）分工 ，领域模型划分。
  4. 服务的部署（是否是自动化部署）。

在微服务架构中，有三大难点，那就是服务故障的传播性(熔断)、服务划分 和 分布式事务。在微服务设计时，一定要考虑清楚这三个场景，从而选择合适的框架。目前比较流行的微服务框架有 Spring 社区的 Spring Cloud、 Google 公司的 Kubemetes 等。

  • 为了解决服务故障的传播性，一般的微服务框架都有熔断机制组件，如：Hystrix、Sentinel等。
  • 服务的划分是标准的划分方案的，一般来说根据业务来划分服务，领域驱动设计具有指导作用。
  • 分布式事务一般的解决办法就是两阶段提交或者三阶段提 交，不管使用哪一种都存在事务失败导致数据不一致的情况，关键时刻还得人工去恢复数据。

总之，微服务的设计一定是渐进式的，并且是随着业务的发展而发展的。

Spring Cloud

Spring Cloud 作为 Java 语言的微服务框架，它依赖于 Spring Boot，有快速开发、持续交付和容易部署等特点。 Spring Cloud 的组件非常多，涉及微服务的方方面面，井在开源社区 Spring 和 Netflix、 Pivotal 两大公司的推动下越来越完善，如今 alibaba 也加入到其中。Spring Cloud 在开发部署上继承了Spring Boot 的一些优点，提高其在开发和部署上的效率。 Spring Cloud 的首要目标就是通过提供一系列开发组件和框架，帮助开发者迅速搭建一个分布式的微服务系统。 Spring Cloud 是通过包装其他技术框架来实现的，其提供了开发分布式微服务系统的一些常用组件，例如：服务注册和发现、 配置中心、熔断器、远程调用，路由、微代理、控制总线、全局锁、分布式会话等。

SpringCloud 常用组件表

组件功能 组件名称
服务的注册和发现 Eureka、Nacos、Consul
服务的负载均衡 Ribbon – 负载均衡 + 服务调用
Dubbo（严格的说，Dubbo只是内部集成了LoadBalance的能力，一般并不会作为负载均衡器使用）
服务的相互调用 OpenFeign – 基于Controller的restful风格的HTTP协议进行网络通信
Dubbo – 基于Netty进行网络通信
服务的容错 Hystrix、Sentinel
服务网关 Gateway、Zuul
服务配置的统一管理 Config-server、Nacos、Apollo
服务消息总线 Bus
服务安全组件 Security、Oauth2.0
服务监控 Admin、jvm
链路追踪 Sleuth、Zipkin

SpringCloud 只是微服务架构的一种具体实现方式，目前开发中常用的落地实现有三种:

  • Dubbo + Zookeeper 半自动化的微服务实现架构
  • SpringCloud Netflix 一站式微服务架构
  • SpringCloud Alibaba 新的一站式微服务架构

参考文档：

分布式和微服务是什么？二者的区别又是什么？