作业一：

第一题



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



解答：

Dubbo 是基于 JAVA 的开源 RPC 框架。

按照微服务的三个角色，服务注册中心、服务消费者、服务提供者，以一次微服务调用为内容，可以画出下面的时序图：

简化的描述如下：

1. 服务提供者注册到服务注册中心，把服务映射到服务提供者列表；

2. 服务消费者程序调用服务接口；

3. 接口访问代理获取到服务消费者调用的接口；

4. 服务框架客户端，调用服务提供者列表找到服务提供者；

5. 负载均衡策略分配一个服务给服务框架客户端；

6. 远程通讯模块与客户端建立连接；

7. 远程通信模块，调用服务调用线程；

8. 服务调用线程请求服务提供者程序， 服务提供者程序返回服务的结果给服务调用线程；

9. 服务调用线程返回结果给远程通讯模块；

10. 远程通讯模块经过代理，返回结果给并调用消费者程序，得到结果。

作业二：

• 根据当周学习情况，完成一篇学习总结

解答：

微服务架构解决方案就是拆分，将模块独立部署，降低系统耦合性：

纵向拆分：将一个大应用拆分为多个小应用，如果新增业务较为独立，那么就直接将其设计部署为一个独立的 Web 应用系统。

横向拆分：将复用的业务拆分出来，独立部署为微服务，新增业务只需要调用这些微服务即可快速搭建一个应用系统。

微服务框架，都是基于 Web Service 与企业级分布式服务演化而来。

所以核心架构都没变。

• Service Provider: 服务提供者

• Service Requester：服务消费者，客户端

• Service Broker：服务注册中心。服务提供者注册服务到服务注册中心；服务消费者从服务注册中心请求服务，服务注册中心调用服务提供者，最终把结果返回给服务消费者。

微服务框架需求

对于大型互联网系统，除了 Web Service 所规范的服务注册与发现，服务调用等标准功能，还需要微服务框架能够支持：

• 失效转移(Fail Over): 对于大型网站的微服务而言，即使是很少访问的简单服务，也需要集群部署，同时微服务框架还需要支持服务提供者的失效转移机制，以实现服务高可用。

• 负载均衡：对于集群部署的服务提供者，服务请求者可以使用加权轮询等手段访问，使服务提供者集群实现负载均衡。

• 高效的远程通信： 对于大型网站，核心服务每天的调用次数会达到数以亿计，如果没有高效的远程通信手段，服务调用可能会成为整个系统性能的瓶颈。

• 对应用最少侵入： 网站技术是为业务服务服务的，是否使用微服务需要根据业务发展规划，微服务也需要渐进式的演化，甚至会出现反复，即使用了微服务后又退回到集中式部署，微服务框架需要支持这种渐进式演化和反复。当然服务模块本身需要支持可集中式部署，也可分布式部署。

• 版本管理：为了应对快速变化的需求，服务版本升级不可避免，如果仅仅是服务实现升级，那么这种升级对服务请求者而言是透明的，无需关注。但是如果服务的访问接口发生变化，就需要服务请求者和服务提供者同时升级才不会导致服务器调用失败。企业应用系统可以申请停机维护，同时升级接口，而网站服务不可能中断，需要服务提供者先升级接口，并同时提供历史版本的服务供请求者调用，当请求者访问接口升级后才可以关闭历史版本服务。（阿里的对升级以后服务维护半年，半年以后就下线。）

微服务架构实践

• 业务先行，先理顺业务边界和依赖，技术是手段而不是目的。

• 先有独立的模块，后有分布式的服务。

• 业务耦合严重，逻辑复杂多变的系统进行微服务重构要谨慎。

• 要搞清楚实施微服务的目的是什么，业务复用？开发边界清晰？分布式集群提升性能？