SOA与微服务

来自软考论文

一、微服务架构介绍

二、出现和发展

三、传统开发模式和微服务的区别

四、微服务的具体特征

五、SOA和微服务的区别

六、如何具体实践微服务

八、微服务的优点和缺点

九、思考：意识的转变

 

• 微服务架构介绍  

微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。

 

主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。

 

• 传统开发模式和微服务的区别

优点：

 

① 开发简单，集中式管理

 

② 基本不会重复开发

 

③ 功能都在本地，没有分布式的管理和调用消耗

 

缺点：（围绕系统质量评估）

 

1、效率低：开发都在同一个项目改代码，相互等待，冲突不断

 

2、维护难：代码功功能耦合在一起，新人不知道何从下手

 

3、不灵活：构建时间长，任何小修改都要重构整个项目，耗时

 

4、稳定性差：一个微小的问题，都可能导致整个应用挂掉

 

5、扩展性不够：无法满足高并发下的业务需求

 

常见的系统架构遵循的三个标准和业务驱动力：

 

1、提高敏捷性：及时响应业务需求，促进企业发展

 

2、提升用户体验：提升用户体验，减少用户流失

 

3、降低成本：降低增加产品、客户或业务方案的成本

 

基于微服务架构的设计：

 

目的：有效的拆分应用，实现敏捷开发和部署

 

• 微服务的具体特征（脑子里有api gateway的图就能记住）

1、分布式服务组成的系统

2、按照业务，而不是技术来划分组织

3、每个服务为独立的业务开发

4、强服务个体和弱通信（Smart endpoints and dumb pipes）

5、自动化运维（DevOps）

6、高度容错性

7、快速演化和迭代

五、SOA和微服务的区别

SOA和微服务的主要区别：

微服务剔除SOA中复杂的ESB企业服务总线，使用Http（Rest API）进行轻量化通讯

        SOA强调按水平架构划分为：前、后端、数据库、测试等，微服务强调按垂直架构划分，按业务能力划分，每个服务完成一种特定的功能，服务即产品

          SOA架构强调的是异构系统之间的通信和解耦合；（一种粗粒度、松耦合的服务架构）

         微服务架构强调的是系统按业务边界做细粒度的拆分和部署。

 

注意：异构数据库系统是相关的多个数据库系统的集合，可以实现数据的共享和透明访问

 

六、怎么具体实践微服务

 

要实际的应用微服务，需要解决一下四点问题：

 

1、客户端如何访问这些服务

 

2、每个服务之间如何通信

 

3、如此多的服务，如何实现？

 

4、服务挂了，如何解决？（备份方案，应急处理机制）

 

1. 客户端如何访问这些服务

 

为了实现统一的地方维护管理，在后台N个服务和UI之间一般会一个代理或者叫API Gateway，其作用包括：

 

• 提供统一服务入口，让微服务对前台透明（前台）

 

• 聚合后台的服务，节省流量，提升性能（后台）

 

• 提供安全，过滤，流控等API管理功能 （本身）

 

API Gateway提供后台服务的聚合的作用，提供一个统一的服务入口，解除客户端和服务端之间的耦合，但API Gateway也有可能成为单点故障点或者性能的瓶颈。

 

2、每个服务之间如何通信

 

所有的微服务都是独立的Java进程 , 跑在独立的虚拟机上，所以服务间的通信就是IPC（inter process communication），目前已经有很多成熟的方案。现在基本最通用的有两种方式：

 

同步调用：

 

① REST（Spring Boot）

 

② RPC（Dubbo）

 

异步(基于消息通信)(Kafka, RabbitMQ)    (点对点和发布/订阅)

 

(Rest)一般REST基于HTTP，更容易实现和接受，服务端实现技术也更灵活些，各个语言都能支持，同时能跨客户端，对客户端没有特殊的要求，只要封装了HTTP的SDK就能调用，所以相对使用的广一些。(RPC)RPC也有自己的优点，传输协议更高效，安全更可控，特别在一个公司内部，如果有统一个的开发规范和统一的服务框架时，他的开发效率优势更明显些。

（注意：这里所说的同步和异步是指时间和操作上的同步还是异步）

 

1. 如此多的服务，如何实现？

（服务之间如何相互感知？服务如何管理？）

 

在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力，增加新的服务节点。所以涉及到服务发现的问题。（服务发现）服务发现通常有两类做法。基本都是通过ZK等类似技术做服务注册信息的分布式管理。(服务注册)当服务上线时，服务提供者将自己的服务信息注册到ZK（或类似框架），并通过心跳维持长链接，实时更新链接信息。（服务寻址）服务调用者通过ZK寻址，根据可定制算法找到服务，还可以将服务信息缓存在本地以提高性能。当服务下线时，ZK会发通知给服务客户端。这种方式的优点是架构简单，扩展灵活，只对服务注册器依赖。但客户端要维护所有调用服务的地址，有技术难度，一般大公司都有成熟的内部框架支持，比如Dubbo。

 

4、服务挂了，如何解决

（分布式的缺点？服务的组成方式？确保链路正常的手段？）

 

分布式最大的特性是网络是不可靠的。为了能降低这个风险，我们的系统是由一系列的服务调用链组成，同时必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多：① 重试机制② 限流③ 熔断机制④ 负载均衡⑤ 降级

 

八、优点和缺点

 

1、微服务的优点：

 

关键点：复杂度可控，独立按需扩展，技术选型灵活，容错，可用性高

注意：下面的概述只要能大致说明即可

 

 

① 它解决了复杂性的问题。它会将一种怪异的整体应用程序分解成一组服务。虽然功能总量 不变，但应用程序已分解为可管理的块或服务。每个服务都以RPC或消息驱动的API的

 

形式定义了一个明确的边界；Microservice架构模式实现了一个模块化水平。

 

② 这种架构使每个服务都能够由专注于该服务的团队独立开发。开发人员可以自由选择任何有用的技术，只要该服务符合API合同。当然，大多数组织都希望避免完全无政府状态并

 

限制技术选择。然而，这种自由意味着开发人员不再有义务使用在新项目开始时存在的可能过时的技术。在编写新服务时，他们可以选择使用当前的技术。此外，由于服务相对较小，因此使用当前技术重写旧服务变得可行。

 

③ Microservice架构模式使每个微服务都能独立部署。开发人员不需要协调部署本地服务的变更。这些变化可以在测试后尽快部署。例如，UI团队可以执行A | B测试，并快速迭代

 

UI更改。Microservice架构模式使连续部署成为可能。

 

④ Microservice架构模式使每个服务都可以独立调整。您可以仅部署满足其容量和可用性限制的每个服务的实例数。此外，您可以使用最符合服务资源要求的硬件。

 

 

 

2、微服务的缺点

 

关键点（挑战）：多服务运维难度，系统部署依赖，服务间通信成本，数据一致性，系统集成测试，重复工作，性能监控等

注意：下面的概述只要能大致说明即可

 

① 一个缺点是名称本身。术语microservice过度强调服务规模。但重要的是要记住，这是一种手段，而不是主要目标。微服务的目标是充分分解应用程序，以便于敏捷应用程序开发和部署。

 

② 微服务器的另一个主要缺点是分布式系统而产生的复杂性。开发人员需要选择和实现基于消息传递或RPC的进程间通信机制。此外，他们还必须编写代码来处理部分故障，因为请求的目的地可能很慢或不可用。

 

③ 微服务器的另一个挑战是分区数据库架构。更新多个业务实体的业务交易是相当普遍的。但是，在基于微服务器的应用程序中，您需要更新不同服务所拥有的多个数据库。使用分布式事务通常不是一个选择，而不仅仅是因为CAP定理。许多今天高度可扩展的NoSQL数据库都不支持它们。你最终不得不使用最终的一致性方法，这对开发人员来说更具挑战性。

 

④ 测试微服务应用程序也更复杂。服务类似的测试类将需要启动该服务及其所依赖的任何服务（或至少为这些服务配置存根）。再次，重要的是不要低估这样做的复杂性。

 

⑤ Microservice架构模式的另一个主要挑战是实现跨越多个服务的更改。例如，我们假设您正在实施一个需要更改服务A，B和C的故事，其中A取决于B和B取决于C.在单片应用程序中，您可以简单地更改相应的模块，整合更改，并一次性部署。相比之下，在Microservice架构模式中，您需要仔细规划和协调对每个服务的更改。例如，您需要更新服务C，然后更新服务B，然后再维修A.幸运的是，大多数更改通常仅影响一个服务，而需要协调的多服务变更相对较少。

 

⑥ 部署基于微服务的应用程序也更复杂。单一应用程序简单地部署在传统负载平衡器后面的一组相同的服务器上。每个应用程序实例都配置有基础架构服务（如数据库和消息代理）的位置（主机和端口）。相比之下，微服务应用通常由大量服务组成。例如，每个服务将有多个运行时实例。更多的移动部件需要进行配置，部署，扩展和监控。此外，您还需要实现服务发现机制，使服务能够发现需要与之通信的任何其他服务的位置（主机和端口）。传统的基于故障单和手动操作的方法无法扩展到这种复杂程度。因此，成功部署微服务应用程序需要开发人员更好地控制部署方法，并实现高水平的自动化。

 

九、思考：意识的转变

 

微服务对我们的思考，更多的是思维上的转变。对于微服务架构：技术上不是问题，意识比工具重要。