【架构】分布式服务架构与微服务架构

---

0）服务相关架构的演变

传统单体架构 ==> 分布式架构 ==> 面向服务（SOA）架构 ==> 微服务架构

• 传统单体架构：如分层架构模式。
  • 应用场景：并发量比较少的，如政府项目、管理系统、ERP、OA、人事管事系统等。
  • 详细可移步《【架构】了解常见的软件架构》。
• 分布式架构：基于传统单体架构演变过来的，会根据不同的业务实现拆分n多个不同子系统。
  • 如京东官网。每个子系统中都有自己的团队来实现开发，具有独立数据库、独立缓存、独立mq，最终实际根据多个不同域名实现跳转整合成一个大项目。
  • 详细可移步《【架构】分布式系统及相关技术栈初了解》。
• 面向服务（SOA）架构：将整个项目中共同的业务逻辑抽取成一个公共的服务，提供给其他的服务实现调用，调用的过程会涉及到RPC远程调用技术。
  • SOA架构模式实现方案为Web Service或者是ESB企业服务总线。
  • 底层通讯协议SOAP协议（Http+XML）实现传输。
  • 传统政府、银行项目还是保留地在使用Web Service。
• 微服务架构：比SOA架构对服务拆分的粒度更加精细，让业务界限更加清晰，每个服务独立部署、互不影响。
  • 服务与服务之间的通讯协议采用restful形式。
  • 数据交换格式采用http+json格式实现传输。

*关于面向对象、面向组件、面向服务

• 这些都是解决问题的思维模式和执行方法，都强调“面向”是因为它们解决问题的出发角度不同。

• 面向对象编程(Object-Oreinted Programming) ：是一种编程范式，指在设计程序时大量运用类实例对象的方式。

  • OOP主要思想是把构成问题的各个事务分解成各个对象，建立对象的目的不是为了完成一个步骤，而是为了描叙一个事物在整个解决问题的步骤中的行为。
  • 类是具有相同特性（数据元素）和行为（功能）的对象的抽象。

• 面向服务架构(Service-Oreinted Architecture) ：是将软件设计成一组可互操作的服务的一套原则或方法论。

  • 通常在考虑系统架构时才会触及SOA。

• 基于组件开发(Component-Based Development) ：是一种软件工程实践，设计时通常要求组件之间高内聚，松耦合。

  • 其接口可能是OO的，调用方式可能是以Service的方式。
  • 基于组件开发关注系统层次、子系统边界和子系统间通讯的的设计。
    
    

三者身处于软件开发的不同层面，不论是哪个领域的软件开发，都可能要同时面对OOP、SOA和CBD。

---

1）面向服务架构（SOA）

1.1 什么是面向服务架构（SOA）？

面向服务架构（Service-Oriented Architecture，SOA）又称为面向服务的体系架构。

• 是一种思想，一种方法论，一种分布式的服务架构。
  • W3C 的定义：SOA 是一种应用程序架构，在这种架构中，所有功能都定义为独立的服务，这些服务带有定义明确的可调用接口，能够以定义好的顺序调用这些服务来形成业务流程。
    • 接口应该独立于实现服务的硬件平台、操作系统和编程语言，使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
  • Service-architecture.com 的定义：SOA 本质上是服务的集合，服务之间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。
    • 服务是精确定义、封装完善、独立于其他服务所处环境和状态的函数。
    • 服务之间需要某些方法进行连接。
  • Gartner 的定义：SOA 是一种 C/S 架构的软件设计方法，应用由服务和服务使用者组成。
    • SOA 与大多数通用的 C/S 架构模型不同之处，在于它着重强调构件的松散耦合，并使用独立的标准接口。
• SOA模型示例：
  
  • 在 SOA 模型中，所有的功能都定义成了独立的服务，服务之间通过交互和协调完成业务的整体逻辑。
  • 所有的服务通过服务总线或流程管理器来连接。
  • 这种松散耦合的架构使得各服务在交互过程中无需考虑双方的内部实现细节，以及部署在什么平台上。
• 服务的基本结构：
  
  • 服务模型的表示层从逻辑层分离出来，中间增加了服务对外的接口层。
  • 通过服务接口的标准化描述，使得服务可以提供给在任何异构平台和任何用户接口使用。

• 传统的Web（HTML/HTTP）技术有效的解决了人与信息系统的交互和沟通问题，极大的促进了B2C模式的发展。
• WEB服务（XML/SOAP/WSDL）技术则是要有效的解决信息系统之间的交互和沟通问题，促进B2B/EAI/CB2C的发展。
• SOA（面向服务的体系）则是采用面向服务的商业建模技术和WEB服务技术，实现系统之间的松耦合，实现系统之间的整合与协同。
  • WEB服务和SOA的本质思路在于使得信息系统个体在能够沟通的基础上形成协同工作。

1.2 为什么需要SOA？

SOA凭借其松耦合的特性，使得企业可以按照模块化的方式来添加新服务或更新现有服务，以解决新的业务需要。

• SOA的灵活性和业务相关性，使得它成为解决企业业务发展需求与企业IT支持能力之间矛盾的最佳方案。

• 灵活性：SOA是第一个考虑了企业业务发展长期性的IT架构。从本质上说，SOA是一组松耦合的服务，每一个服务的建立和替换都是相对简单的。

  • 在SOA中，可以用一个服务替换另一个服务而无须关心其底层的实现技术，唯一要考虑的就是服务接口。
  • SOA还可以充分利用企业现有的IT资源，包括企业已有的应用和数据库。
    • 新系统可以通过将已有应用和数据融入SOA，而不是替换它们，来使其成为企业整体解决方案的一部分。
    • 这种方式最终将使企业的IT架构能够更快速、更有效地适应业务需求的变化。
      
      

• 业务相关性：SOA与其他IT架构的最大区别在于它与业务的关联性。

  • 它是以“服务”为基本单元来组织IT资源，其中的每一项服务都可以完成实际业务流程中的一项任务。
    • 例如，可以把一项服务叫做“打印发票”，它可能包含计算收入、查找相应税率、计算应缴税款、打印发票等一系列操作。
    • 这样一来，服务就与业务产生了密切的联系，业务人员也可以参与服务的创建并且用它们定义新的业务流程。

1.3 SOA 的特征

• SOA要解决的主要问题是：快速构建与应用集成。

• 实施SOA的关键目标是：实现企业IT资产的最大化作用。

• 可重用：一个服务创建后能用于多个应用和业务流程。
• 松耦合：服务请求者到服务提供者的绑定与服务之间应该是松耦合的。
  • 因此，服务请求者不需要知道服务提供者实现的技术细节，例如程序语言、底层平台等等。
• 明确定义的接口：服务交互必须是明确定义的。
• 无状态的服务设计：服务应该是独立的、自包含的请求，在实现时它不需要获取从一个请求到另一个请求的信息或状态。
  • 服务不应该依赖于其他服务的上下文和状态。
  • 当产生依赖时，它们可以定义成通用业务流程、函数和数据模型。
• 基于开放标准：当前SOA的实现形式是Web服务，基于的是公开的W3C及其他公认标准。
  • 采用第一代Web服务定义的SOAP、WSDL和UDDI以及第二代Web服务定义的WS-*来实现SOA。
• 粗粒度：服务数量不会太多，依靠消息交互而不是远程过程调用，通常消息量比较大，但是服务之间的交互频度较低。

1.4 SOA 的实现方法

SOA 只是一种概念和思想，需要借助于具体的技术和方法来实现它。

• 从本质上来看， SOA 是用本地计算模型来实现一个分布式的计算应用，也有人称这种方法为“本地化设计，分布式工作”模型。
• 目前，实现 SOA 的方法也比较多，其中主流方式有 Web Service、企业服务总线和服务注册表。

1、Web Service

在 Web Service（Web 服务）的解决方案中，一共有三种工作角色，其中服务提供者和服务请求者是必需的，服务注册中心是一个可选的角色。

它们之间的交互和操作构成了 SOA 的一种实现架构：

• 服务提供者：是服务的所有者，该角色负责定义并实现服务。
  • 使用 WSDL 对服务进行详细、准确、规范地描述，并将该描述发布到服务注册中心，供服务请求者查找并绑定使用。
• 服务请求者：是服务的使用者，虽然服务面向的是程序，但程序的最终使用者仍然是用户。
  • 从架构的角度看，服务请求者是查找、绑定并调用服务，或与服务进行交互的应用程序。
  • 服务请求者角色可以由浏览器来担当，由人或程序（例如，另外一个服务）来控制。
• 服务注册中心：是连接服务提供者和服务请求者的纽带，服务提供者在此发布他们的服务描述，而服务请求者在服务注册中心查找他们需要的服务。
  • 不过，在某些情况下，服务注册中心是整个模型中的可选角色。例如，如果使用静态绑定的服务，服务提供者则可以把描述直接发送给服务请求者。

Web Service 模型中的操作包括发布、查找和绑定，这些操作可以单次或反复出现。

• 发布：为了使用户能够访问服务，服务提供者需要发布服务描述，以便服务请求者可以查找它。
• 查找：在查找操作中，服务请求者直接检索服务描述或在服务注册中心查询所要求的服务类型。
  • 对服务请求者而言，可能会在生命周期的两个不同阶段中涉及查找操作：
    • 首先是在设计阶段，为了程序开发而查找服务的接口描述；
    • 其次是在运行阶段，为了调用而查找服务的位置描述。
• 绑定：在绑定操作中，服务请求者使用服务描述中的绑定细节来定位、联系并调用服务，从而在运行时与服务进行交互。
  • 绑定可以分为动态绑定和静态绑定。
    • 在动态绑定中，服务请求者通过服务注册中心查找服务描述，并动态地与服务交互；
    • 在静态绑定中，服务请求者已经与服务提供者达成默契，通过本地文件或其他方式直接与服务进行绑定。

2、服务注册表

服务注册表（service registry）虽然也具有运行时的功能，但主要在 SOA设计时使用。

• 它提供一个策略执行点（Policy Enforcement Point，PEP），在这个点上，服务可以在 SOA 中注册，从而可以被发现和使用。
• 服务注册：是指服务提供者向服务注册表发布服务的功能（服务合约），包括服务身份、位置、方法、绑定、配置、方案和策略等描述性属性。
• 服务位置：是指服务使用者，帮助它们查询已注册的服务，寻找符合自身要求的服务。
• 服务绑定：服务使用者利用查找到的服务合约来开发代码，开发的代码将与注册的服务进行绑定，调用注册的服务，以及与它们实现互动。

3、企业服务总线（ESB）

ESB 是由中间件技术实现并支持 SOA的一组基础架构，是传统中间件技术与 XML、 Web Service 等技术结合的产物，是在整个企业集成架构下的面向服务的企业应用集成机制。

• ESB 提供了一种基础设施，消除了服务请求者与服务提供者之间的直接连接，使得服务请求者与服务提供者之间进一步解耦。
• 在企业应用集成方面，与现存的、专有的集成解决方案相比，ESB 具有以下优势：
  • 扩展的、基于标准的连接：使得在系统内部和整个价值链中可以容易地进行异步或同步数据交换。
    • ESB 通过使用 XML、SOAP 和其他标准，提供了更强大的系统连接性。
  • 灵活的、服务导向的应用组合：基于 SOA，ESB 使复杂的分布式系统（包括跨多个应用、系统和防火墙的集成方案）能够由以前开发测试过的服务组合而成，使系统具有高度可扩展性。
  • 减少市场反应时间，提高生产率：ESB 通过构件和服务复用，按照 SOA 的思想简化应用组合，基于标准的通信、转换和连接来实现这些优点。

1.5 SOA 的关键技术

与 SOA 紧密相关的技术主要有 UDDI、WSDL、SOAP 和 REST 等，而这些技术都是以 XML 为基础而发展起来的。

• UDDI

  UDDI（Universal DescriptionDiscovery and Integration，统一描述、发现和集成）提供了一种服务发布、查找和定位的方法。

  • UDDI 规范描述了服务的概念，同时也定义了一种编程接口。
  • 通过 UDDI 提供的标准接口，企业可以发布自己的服务供其他企业查询和调用，也可以查询特定服务的描述信息，并动态绑定到该服务上。
  • 在 UDDI 技术规范中，主要包含以下三个部分的内容：
    • 数据模型：UDDI 数据模型是一个用于描述业务组织和服务的 XML Schema。
    • API：UDDI API 是一组用于查找或发布 UDDI 数据的方法，UDDI API 基于 SOAP。
    • 注册服务：UDDI 注册服务是 SOA 中的一种基础设施，对应着服务注册中心的角色。
      
      

• WSDL

  WSDL（Web ServiceDescription Language，Web 服务描述语言）是对服务进行描述的语言，它有一套基于 XML 的语法定义。

  • WSDL 描述的重点是服务，它包含服务实现定义和服务接口定义：
    
    
    

• SOAP

  SOAP（Simple ObjectAccess Protocol，简单对象访问协议）定义了服务请求者和服务提供者之间的消息传输规范。

  • SOAP 用 XML 来格式化消息，用 HTTP 来承载消息。
  • 通过 SOAP，应用程序可以在网络中进行数据交换和远程过程调用（Remote Procedure Call， RPC）。
  • SOAP 主要包括以下四个部分：
    • 封装：定义了一个整体框架，用来表示消息中包含什么内容，谁来处理这些内容，以及这些内容是可选的还是必需的。
    • 编码规则：定义了一种序列化的机制，用于交换系统所定义的数据类型的实例。
    • RPC 表示：定义了一个用来表示远程过程调用和应答的协议。
    • 绑定：定义了一个使用底层传输协议来完成在节点之间交换 SOAP 封装的约定。
      
      

• REST

  REST（RepresentationalState Transfer，表述性状态转移）是一种只使用 HTTP 和 XML 进行基于 Web 通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。

  • REST 从根本上来说只支持几个操作（POST、GET、PUT 和 DELETE），这些操作适用于所有的消息。

---

2）微服务架构

2.1 什么是微服务架构？

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。

• 每个服务运行在其独立的进程中，互不影响。
• 服务与服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 协议的 RESTful API）。
• 每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。
  • 对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

2.2 为什么需要微服务架构？

微服务架构是从soa架构模式演变过来的，比SOA架构对服务拆分的粒度更加精细，让业务界限更加清晰。

• SOA 早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高，新系统稳定性的收敛也需要一些时间，最终 SOA 看起来很美，但却成为了企业级奢侈品，中小公司都望而生畏。
• 此外，实施SOA时会遇到很多问题，比如通信协议（例如SOAP）的选择、第三方中间件如何选择、服务粒度如何确定等，目前也存在一些关于如何划分系统的指导性原则，但其中有很多都是错误的。SOA并没有告诉你如何将单体应用划分成微服务，所以在实施SOA时会遇到很多问题。

*基于服务总线的设计：

• 总线则作为中枢系统，提供统一的服务入口，并实现了服务统一管理、服务路由、协议转换、数据格式转换等功能。
• 是SOA的一种很常见的设计实践，能够将不同系统有效地连接起来，并大大降低了连接数（每个子系统只需要和总线建立连接）和系统间连接拓扑的复杂度。
  
• 基于服务总线的设计，往往需要ESB（Enterprise Service Bus，企业服务总线）产品来充当基础设施。
• 在其内部设计和实现中，通常会应用到一些经典的架构模式，例如：Broker模式、消息总线模式、管道过滤器模式、发布订阅模式等。具体介绍可参考：https://blog.csdn.net/dinglang_2009/article/details/44516657

• 背景（微服务架构之前）：

  传统企业或者很多企业的软件，大多不止一套系统，都是各个独立大系统的堆砌。通常存在扩展性差、可靠性不高、维护成本大、重复轮子很多等问题。
  • 对于上述这些问题，可以想到的解决方案有：组件化、服务化。
    
    

• 微服务架构提供的解决方案：

  微服务架构将各个组件或者模块分散到各个服务中，对整个系统实现解耦。那微服务架构强调的重中之重就是业务系统需要完善的组件化和服务化。
  • 组件化：将一个大系统，按照一定的业务或者技术维度关注形式，拆分成独立的组件。
    • 目的是为了分而治之，为了可重用，为了减少耦合度。
    • 比如按照技术维度：搜索组件、缓存组件；按照业务维度：用户中心、支付中心等
  • 服务化：是一种以服务为中心的解决方案：服务注册、服务发布、服务调用、服务监控、服务负载均衡等。
    • 核心就是不同服务之间的通信。
    • 服务化之前：代码重复、可维护性低、DB 访问耦合等
    • 服务化后的好处：调用简单、代码复用、业务隔离、数据库解耦等

2.3 微服务优点

• 技术异构性：

  不同服务内部的开发技术可以不一致，你可以用java来开发helloworld服务A，用golang来开发helloworld服务B。
  • 为不同的服务选择最适合该服务的技术，系统中不同部分也可以使用不同的存储技术，比如A服务可以选择redis存储，B服务你可以选择用MySQL存储，这都是允许的。

• 隔离性：

  一个服务不可用不会导致另一个服务也瘫痪，因为各个服务是相互独立和自治的系统。
  • 这在单体应用程序中是做不到的，单体应用程序中某个模块瘫痪，必将导致整个系统不可用，当然，单体程序也可以在不同机器上部署同样的程序来实现备份，不过，同样存在资源浪费问题。
    
    

• 可扩展性：

  可以只对那些影响性能的服务做扩展升级，这样对症下药的效果是很好的。
  • 庞大的单体服务如果出现性能瓶颈只能对软件整体进行扩展，可能真正影响性能的只是其中一个很小的模块，我们也不得不付出升级整个应用的代价，这在微服务架构中得到了改善。
    
    

• 简化部署：

  在微服务架构中，各个服务的部署是独立的，如果真出了问题也只是影响单个服务，可以快速回滚版本解决。
  • 如果你的服务是一个超大的单体服务，有几百万行代码，即使修改了几行代码也要重新编译整个应用，这显然是非常繁琐的，而且软件变更带来的不确定性非常高，软件部署的影响也非常大。
    
    

• 易优化：

  微服务架构中单个服务的代码量不会很大，这样当你需要重构或者优化这部分服务的时候，就会容易很多，毕竟，代码量越少意味着代码改动带来的影响越可控。

2.4 微服务架构存在的问题

• 服务注册与发现：

  微服务之间相互调用完成整体业务功能，需要考虑如何在众多微服务中找到正确的目标服务地址。
  • 这就是所谓「服务发现」功能，常用的做法是：
    • 服务提供方启动的时候把自己的地址上报给「服务注册中心」，这就是「服务注册」。
    • 服务调用方「订阅」服务变更「通知」，动态的接收服务注册中心推送的服务地址列表，以后想找哪个服务直接发给他就可以。
  • 分布式服务注册与发现（eureka、consul、zookeeper、Nacos）
  • 分布式事务解决方案（rabbitmq、rocketmq事务消息、lnc（淘汰）、setata）最终一致性概念
  • 分布式任务调度平台（XXL-Job、AlibabaCloud Scheduler、elastic-job）
    
    

• 运维成本：

  微服务将系统分成多个独立的部分，每个部分都是可以独立部署的业务单元。这就意味着，在微服务架构下，随着服务数量的增多，每个服务都需要独立的配置、部署、监控、日志收集等，因此成本呈指数级增长。
  • 这就需要我们有一套完备的服务监控体系，包括拓扑关系、监控（Metrics）、日志监控（Logging）、调用追踪（Trace）、告警通知、健康检查等，防患于未然。
  • 分布式日志采集系统elk+kafka
  • 分布式服务追踪与调用链系统Zipkin
    
    

• 部署自动化：

  对于微服务架构而言，每个服务都是一个独立可部署的业务单元，每个服务的修改都需要独立部署。如何有效地构建自动化部署流水线，降低部署成本、提高部署频率，是微服务架构下需要面临的一个挑战。
  • 分布式服务配置中心（springcloud config/nacos/disconfig/携程阿波罗）
    
    

• 服务容错：

  • 生产环境复杂多变，服务运行过程中不可避免的发生各种故障（宕机、过载等等），需要引入「熔断、隔离、限流和降级、超时机制」等「服务容错」机制来保证服务持续可用性。
  • 微服务是拆分成多个服务进行部署，服务间的通信都是通过网络，此时的性能会受影响。同时可靠性也会受影响。数据一致性也需要严格控制，其成本也比单块系统高。
    
    

• 服务治理：

  由于微服务架构是把系统拆分为若干个可独立部署的服务，所以需要：
  • 进行服务间的依赖测试：在服务数量较多的情况下，如何有效地保证服务之间能有效按照接口的约定正常工作，成为微服务实施过程中必须面临的巨大挑战。
  • 随着微服务个数的增多，如何清晰有效地展示服务之间的依赖关系，成为了一个挑战。
    
    

• 服务安全：

  有些服务的敏感数据存在安全问题，「服务安全」就是对敏感服务采用安全鉴权机制，对服务的访问需要进行相应的身份验证和授权，防止数据泄露的风险。
  
  

• DevOps 与组织结构：

  传统单块架构中，团队通常是按技能划分，如开发部、测试部、运维部，并通过项目的方式协作，完成系统交付。而在微服务架构的实施过程中，在组织或者团队层面，如何传递 DevOps 文化的价值，让团队理解 DevOps 文化的价值，并构建全功能团队，也是一个不小的挑战。
  • 微服务不仅表现出一种架构模型，同样也表现出一种组织模型。
  • 这种新型的组织模型意味着开发人员和运维的角色发生了变化，开发者将承担起服务整个生命周期的责任，包括部署和监控，而运维也越来越多地表现出一种顾问式的角色，尽早考虑服务如何部署。
  • 因此，如何在微服务的实施中，按需调整组织架构，构建全功能的团队，是一个不小的挑战。

2.5 常见的微服务框架

• Dubbo

  Dubbo是阿里巴巴开源的基于 Java 的高性能 RPC（一种远程调用） 分布式服务框架（SOA），致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。

  • Dubbo 提供的基础能力包括：服务发现、流式通信、负载均衡、流量治理等等。

  • 提供的通信模型：同步的 Request-Response （默认）、消费端异步请求、提供端异步执行、消费端请求流、提供端响应流、双向流式通信。

  • Dubbo 提供的是 Client-Based 的服务发现机制，使用者可以有多种方式启用服务发现：

    • 使用独立的注册中心组件，如 Nacos、Zookeeper、Consul、Etcd 等。
    • 将服务的组织与注册交给底层容器平台，如 Kubernetes。

  • 部署架构：为了在分布式环境下实现各个微服务组件间的协作， Dubbo 定义了一些中心化组件。

    • 注册中心
    • 配置中心
    • 元数据中心

  • 文档：https://dubbo.apache.org/zh/
    
    

• Tars：

  腾讯内部使用的微服务架构 TAF（Total Application Framework）多年的实践成果总结而成的开源项目。

  • 仅支持 C++ 语言，目前在腾讯内部应用也非常广泛。2017 年对外开源，仅支持 C++ 语言。
    

  • 源码：https://github.com/TarsCloud/Tars/
    
    

• Motan：

  是新浪微博开源的一个Java 框架。Motan 在微博平台中已经广泛应用，每天为数百个服务完成近千亿次的调用。于 2016 年对外开源，仅支持 Java 语言。
  
  • 官方指南：https://github.com/weibocom/motan/wiki/zh_userguide
    
    

• gRPC：

  是Google开发的高性能、通用的开源RPC框架，其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计，基于ProtoBuf(Protocol Buffers)序列化协议开发。
  • 本身它不是分布式的，所以要实现上面的框架的功能需要进一步的开发。2015 年对外开源的跨语言 RPC 框架，支持多种语言。
    
  • 中文教程：https://doc.oschina.net/grpc?t=58008
    
    

• thrift：

  最初是由 Facebook 开发的内部系统跨语言的高性能 RPC 框架，2007 年贡献给了 Apache 基金，成为 Apache 开源项目之一， 跟 gRPC 一样，Thrift 也有一套自己的接口定义语言 IDL，可以通过代码生成器，生成各种编程语言的 Client 端和 Server 端的 SDK 代码，支持多种语言。

*微服务框架与RPC

• 什么是RPC？

  RPC (Remote Procedure Call）远程过程调用是一个计算机通信协议。我们一般的程序调用是本地程序内部的调用，RPC允许你像调用本地函数一样去调用另一个程序的函数，这中间会涉及网络通信和进程间通信，但你无需知道实现细节，RPC框架为你屏蔽了底层实现。

  • RPC是一种服务器-客户端（Client/Server）模式，经典实现是一个通过发送请求-接受回应进行信息交互的系统。

• 两者关系：

  微服务框架一般都包含了RPC的实现和一系列「服务治理」能力，是一套软件开发框架。

  • 我们可以基于这个框架之上实现自己的微服务，方便的利用微服务框架提供的「服务治理」能力和RPC能力，所以微服务框架也被有些人称作RPC框架。

2.6 微服务与SOA的关系

微服务可以说是 SOA 的一种，但两者之间存在一些差异：

• 通讯协议：微服务架构基于SOA架构，继承了SOA架构优点，在微服务架构中去除SOA架构中SOAP协议和ESB企业服务总线，改为http+json形式传输接口。
• 服务拆分：微服务架构比SOA架构的粒度更加精细，提倡让专业的人去做专业的事。每个服务互不影响。每个服务都是单独独立数据库、redis连接、MQ等。并且都是独立部署，整个服务架构更加轻巧。
• 迭代：微服务的架构模式比SOA架构模式，更加适合敏捷、高效、快速迭代。

---

3）分布式服务架构与微服务架构的关系

• 从概念理解：分布式服务架构强调的是服务化以及服务的分散化，微服务则更强调服务的专业化和精细分工。
• 从实践的角度来看：微服务架构通常是分布式服务架构，反之则未必成立。
  • 所以，选择微服务通常意味着需要解决分布式架构的各种难题。

• 微服务架构是团队面对互联网产品爆发式增长的最优选择，要解决的是快速迭代、高可靠和高可用等问题。
  • 把复杂度很高的产品拆分成一些较小的模块，并遵循康威定律，每一个模块用5-9个小团队来维护，这样可以减少沟通成本，提高协作效率，更好地实现快速迭代和弹性扩展。
  • 复杂业务拆分可能无法一步到位，因为复杂，每个业务并不一定只能拆成一个组件，庞大的业务拆分出相对独立和庞大的业务。但如果业务较小而又比较多，且类型相似，也可以不用着急拆分，都是根据实际情况决定的。
    • 中间的状态，可能不是严格意义上的微服务架构，但属于分布式服务架构（不过这不是那么重要，重要的是符合业务发展阶段的需求）。
• 需要注意的是：既没有规模又不需要太多变化的业务，如果采用微服务架构改造，引入各种复杂性，比如部署工作量的增加、复杂链路的监控难题，这就是为微服务而微服务，只会得不偿失。

---

【部分内容参考自】

• 2021-04-28-微服务架构演变过程（一）：https://blog.csdn.net/qq_41270550/article/details/115232732
• 面向对象、面向服务、面向组件三种编程模式有什么区别？分别适用于哪些领域的开发？：https://www.zhihu.com/question/20478119
• 面向服务架构：https://wiki.mbalib.com/wiki/%E9%9D%A2%E5%90%91%E6%9C%8D%E5%8A%A1%E6%9E%B6%E6%9E%84
• SOA/软件架构设计—面向服务的架构（SOA详细解释）：http://www.uml.org.cn/soa/202004152.asp?artid=23177
• 为什么要微服务架构服务化？：https://blog.csdn.net/jeffli1993/article/details/110234389
• 一、微服务架构演变过程：https://www.cnblogs.com/ylcc-zyq/p/13131599.html
• 什么是微服务架构？：https://zhuanlan.zhihu.com/p/345552079
• 分布式服务架构与微服务架构概念的区别与联系是怎样的？：https://www.zhihu.com/question/28253777