作业一

题目一: Dubbo 微服务调用的时序图

根据微服务框架 Dubbo 的架构图，画出 Dubbo 进行一次微服务调用的时序图

什么是 Dubbo?

Dubbo 是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring 框架无缝集成。

Dubbo 是一款高性能、轻量级的开源 Java RPC 框架，它提供了三大核心能力：

• 面向接口的远程方法调用

• 智能容错和负载均衡

• 以及服务自动注册和发现

Dubbo 的架构框架

Dubbo 进行一次微服务调用的时序图

Dubbo时序图

流程文字说明

1. 服务的提供者在服务的容器中启动

2. 服务管理容器检测服务提供者程序，根据其描述信息，注册给服务注册中心

3. 接口名，IP, 端口

4. 请求参数

5. 运行在哪些服务器上

6. 注册中心记录信息，完成该服务的注册过程

7. 服务的消费者通过 Dubbo 接口调用服务(Java)调用服务

8. 接口包通过 Dubbo 的微服务框架客户端进行调用

9. 微服务框架客户端咨询注册中心进行查找

10. 注册中心返回服务列表，提供服务的信息(在负载均衡策略中进行挑选 IP 和端口)

11. 微服务框架客户端通过远程通讯的模块向 IP 和端口发起请求

12. 服务提供者对 request 进行解析，然后把 request 分发给正确的类，进行处理后返回给微服务框架客户端

13. 微服务框架客户端再通过接口代理返回信息给消费者程序

题目二: 微服务架构的思考和认识

关于微服务架构（中台架构、领域驱动设计、组件设计原则），你有什么样的思考和认识？

微服务概念:

微服务架构的提出者是 ThoughtWorks 首席科学家、世界知名软件架构大师 Martin Fowler，他于 2014 年在自己的博客上发表了名为《微服务架构》的博文，对这一架构理念进行了系统的梳理。

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务于服务之间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

传统的开发模型，如经典的 Spring 分层模式——Controller/Service/Dao，就是所谓的贫血模型。我们绝大多数人在使用 Spring，只是使用 OO 语言开发，而不是 OO 开发；对象只是数据的载体，并没有行为。简单的业务系统采用这种贫血模型和过程化设计是没有问题的，但在业务逻辑复杂了，业务逻辑、状态会散落到在不同 Service 的不同方法中，原本的代码意图会渐渐不明确，我们将这种情况称为由贫血症引起的失忆症。相比之下，比较优异的抽象手段是采用领域模型的开发方式，将数据和行为封装在一起，并与现实世界中的业务对象相映射。各类具备明确的职责划分，将领域逻辑分散到领域对象中。

解决复杂和大规模软件的方法论可以被粗略地归为三类：抽象、分治和知识。

• 分治：把问题空间分割为规模更小且易于处理的若干子问题

• 抽象：使用抽象能够精简问题空间，而且问题越小越容易理解

• 知识：顾名思义，DDD、组件设计原则等等可以认为是知识的一种，让我们知道如何抽象出限界上下文以及如何去分治。

微服务的架构方式：

微服务架构其实是一种架构风格，即按照领域把关联紧密的一组服务部署为一个应用，对外提供服务。整个系统由多个这样的应用组成。微服务架构同时也是一种组织风格，正如康威定律里描述的一样：一个组织的系统通常被设计成这个组织通信结构的副本，一个应用被一个小团队负责，这个团队既有产品负责人，也有开发工程师、设计师和测试工程师，既有负责某一个业务线的团队，也有做基础支撑的中间件团队。整个系统由多个这样的小团队组成，各自自主的发展和演进。

微服务架构其实并不是一个全新的概念，它是从分布式架构和面向服务的架构进化而来的。

• 分布式架构: 由多台服务器组成的网络，也就是把代码分别部署到不同的服务器上，并通过网络进行互联。

• 服务: 一个抽象概念，是代码所提供的业务能力，而非代码所包含的函数功能本身。如果说模块、包是对代码进行划分的方式，那么服务就是对业务进行划分的方式。

在面向服务的架构基础上，微服务架构应运而生。微服务架构汲取了敏捷开发、持续集成/持续交付、自动化部署等新技术的优势，解决了传统的面向服务的架构体量过大、服务契约复杂、集中式管理、技术栈单一等缺点，为面向服务的架构提供了更完善的进化形态。

微服务的应用:

首先，“微”这个字强调的是服务的小型化、单一职能化，但具体多微才算微并没有一个确切的准则，更多的是因人而异，并且微服务架构并不是一次成型的架构，而是一个逐渐渐进演化的架构，因此对于“微”的定义也会随着架构规模和团队发展而有所变化。

服务的划分应当围绕业务进行，服务与服务之间应当是相互独立的。微服务架构是一种分布式架构，服务间应当通过语言无关、平台无关、技术无关的网络通信方式来互通，各个微服务本身可以选择适合业务特性的语言和技术来实现。

我们创建微服务时，事实上就是一个抽象+分治的手段；从复杂系统之中，抽象出一系列高内聚、低耦合的业务，以服务的形式分别运行。怎么提取？一般有两种方式：技术维度和业务维度。技术维度类似 MVC 的横向分层结构，业务维度则是按业务领域的纵向划分系统。微服务架构更强调从业务维度去分治复杂系统，以追求业务层面的复用；DDD 正巧也是以同样的视角去看待业务与技术的关系，在响应业务变化调整业务架构时，也随之变化系统架构。因此，DDD 与当今的微服务架构设计是有天然的契合点的。

微服务解决的问题:

• 服务可以使用不同的语言来实现，并且由于服务之间是通过语言无关的通信机制来沟通，因此可以很容易地实现多版本、多需求的服务共存

• 通过独立的机制随时进行切换，可以快速而灵活地满足各类业务需求。使用微服务的过程可以形象地看作是搭积木，通过将不同业务功能的微服务按照特定的方式进行组合，就能得到不同的业务流程

• 各个微服务彼此独立，开发和部署过程互不影响，可以快速上手开发新服务，并能在有限的用例集下快速地对代码进行修改、测试和升级，而无需影响其他服务的正常运行