架构师训练营第 10 周作业

作业1：根据微服务框架dubbo的架构图，画出dubbo进行一次微服务调用的时序图。

图1 dubbo服务调用序图

图2 dubbo服务架构图



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

第一次听到领域驱动设计是去年在杭州和蚂蚁合作项目时才听到的，后面通过一些技术文档的学习了解了一点中台，不过说实话我对技术属于极度后知后觉的，最近几年一直秉持的思想是在任何一个行业中业务的积累是在该行业立足的根本，对于技术一直都视为工具，各种技术就像是一个工具箱，不管这个工具多么高级，功能多么强大，一切都是以实现业务目标为准则，摒弃一切拿着各种高级锤子到处寻找钉子的行为。技术是随着面临实际业务问题并解决这些问题而逐步演进的，所以任何技术的选用都需要考虑实际的业务场景，不能为了技术而技术。

微服务也是随着互联网业务的快速增长对系统提出的更高的性能和稳定性要求而产生的，面对巨无霸式系统的各种合并、编译、打包、资源瓶颈以及业务扩展等问题，系统拆分解耦就被提到了不可不面对的境地。通过对系统纵向的应用拆分以及横向的服务能力切分，一个个独立的服务协同交互共同对外提供着稳定可靠的服务。这就是将复杂的问题拆解成一个个可以解决的小问题，通过解决一个个的小问题从而解决复杂的大问题，当然现实与理论还是有一定的差异的，在拆解以及解决问题的过程中又会引发一些新的问题，针对这些问题又诞生了各种原则与框架。

记得前两年我们公司对投资研究系统建设规划的很好，设计抽象出了各种集市，然而最终落地的情况并不如人意，现在总结看来有一点特别重要：我们的团队对业务的理解远远不够（全员几乎无相关业务知识与背景，一切均以YY为主）。设计本身就是一门平衡的艺术，当对业务理解不够时，仅凭对各种工具的熟练应用推导业务应该的逻辑，那就是一首歌《我真的以为》。所以我认为是否采用微服务、是否建设大中台、是否需要抽象划分业务领域的基础是要先明确我们的目的是什么？然后再搞清楚我们的业务目标是什么 ？我们的目标用户是谁？我们的业务量有多大？

领域驱动设计（DDD）通过使用统一的领域语言可以有效降低技术人员与业务人员的沟通成本，并能够针对同一问题的理解基本处于相同的位置，对于业务领域的划分怎样划分感觉都没什么错，那么就需要在划分之初统一划分的原则，在战略层面明确服务的边界与关系。例如：通过业务核心主线作为领域划分标准确定出领域、子域、限界上下文以及上下文交互图等内容。

组件的设计原则包括组件耦合原则与组件内聚原则，组件内聚主要考虑组件完整功能的实现需要包含哪些类，组件耦合则要考虑组件之间的关系。在组件设计中不仅要考虑技术还要考虑业务场景，易变与稳定，依赖与被依赖都需要放到实际的业务场景中进行考察验证，另外也需要考虑人的因素、环境的因素等。