根据微服务框架 Dubbo 的架构图，画出 Dubbo 进行一次微服务调用的时序图。
关于微服务架构（中台架构、领域驱动设计、组件设计原则），你有什么样的思考和认识？
对于中台架构，以我个人所在的公司的实际情况来看，中台就是基于基础组件，如 MySQL，Redis，消息队列，ElasticSearch 等，封装的一系列统一的，可以全局公用的基础微服务，比如用户服务，某某数据接口服务，缓存服务，日志记录服务，文件存储服务等。基于中台架构，开发者可以敏捷地开发新的业务系统，服务水平扩展也很容易，部署多份业务代码即可。不过中台架构，也增加了运维层面的复杂度，另外如果需要整套服务给客户部署到其内部环境，也需要整套部署才能正常运行。比起单机的程序，要耗费更多的机器资源。
领域驱动设计，在我看来，短期内团队还吸收不来其思想，毕竟项目需要大家一起协同开发，贫血模型早已根深蒂固，MVC 的开发模型早已深入人心。不过我们还可以吸取其几点思想。比如在软件设计阶段，就抽象出其领域实体，对实体的操作尽可能写到一个 Service 中，尽可能避免混淆。
组件设计，包含三个原则，组件内聚原则，共同封闭原则和共同复用原则。组件内聚原则是指软件复用的最小粒度应该等同于其发布的最小粒度；共同封闭原则是将相同功能的类抽象出来放到一个组件中；共同复用原则，即不要强迫组件的用户依赖他们不需要的东西。
