1.Dubbo 微服务调用时序图

暴露服务时序



引用服务时序





2. 微服务架构认识

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

• 思路1：微服务架构解决了什么问题？

对于大规模的复杂应用，大型应用会显得特别笨重：要修改一个地方就要将整个应用全部部署；编译时间过长；回归测试周期过长；开发效率降低等。另外，大型应用不利于更新技术框架。:

• 思路2：微服务优点及缺点

1. 优点

每个服务足够内聚，足够小，代码容易理解、开发效率提高；

服务之间可以独立部署，微服务架构让持续部署成为可能；

每个服务可以根据自己的需要部署到合适的硬件服务器上；

容易扩大开发团队，可以针对每个服务（service）组件开发团队；

提高容错性（fault isolation），一个服务的内存泄露并不会让整个系统瘫痪；

系统不会被长期限制在某个技术栈上。

1. 缺点

开发人员要处理分布式系统的复杂性；

开发人员要设计服务之间的通信机制，对于需要多个后端服务的user case，要在没有分布式事务的情况下实现代码非常困难；

涉及多个服务直接的自动化测试也具备相当的挑战性；

服务管理的复杂性，在生产环境中要管理多个不同的服务的实例，这意味着开发团队需要全局统筹



应用微服务架构的时机如何把握？对于业务还没有理清楚、业务数据和处理能力还没有开始爆发式增长之前的创业公司，不需要考虑微服务架构模式，这时候最重要的是快速开发、快速部署、快速试错。



• 思路3：微服务的关键问题

1.正确的拆分业务服务，服务划分原则：

（1）每个服务应该尽可能符合单一职责原则

（2）参考Unix命令行工具的设计，Unix提供了大量的简单易用的工具

（3）系统分解的目标并不仅仅是搞出一堆很小的服务，这不是目标；真正的目标是解决大型应用在业务急剧增长时遇到的问题。

2.微服务的通讯机制，客户端与服务器之间的通信加入API gateway，由它负责与客户度对接，并将客户端的请求转化成对内部服务的一系列调用。

3.六种微服务设计模式：聚合器微服务设计模式，代理微服务设计模式，链式微服务设计模式，分支微服务设计模式，数据共享微服务设计模式，异步消息传递微服务设计模式