Week_010 作业

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





答：时序图如下



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

答：

微服务架构是一步步的演变而来的，一般开始的时候大多数企业都是走单机架构；因为在一个初始的项目中，不论模块间的调试还是增加功能都是比较便捷的；

但随着业务的不断增加，业务间的调用逐渐变得十分复杂，原有的单机项目也变成了一个不易维护的代码泥球，各种调用混杂在一起，牵一发而动全身；只能不断地向项目中打补丁似的增加代码。项目越来越臃肿。项目的编译和部署都变得十分困难，效率十分低下；代码的分支管理也变得十分困难。

单体项目中，如果承载了太多功能，那么所有的用户都将访问该单体项目所在服务器或是服务器组；这就会造成：很多用户仅仅只是访问项目中的一小个模块，但该用户造成的资源损耗却要所有的项目一同承担，随着功能越来越多，根据摩尔定律，单服务器的资源不论怎么样都是不够用的。最终只能走拆分系统这条路。

感觉设计的一切都是从业务出发；业务在发展中遇到了问题，找到问题所在，和业务相关的人员在确定术语以后，进行高效的沟通，精准的划分出业务的边界，并以领域驱动设计为指导，化繁为简。

不要为了微服务而微服务，主要的目的还是为了节省企业的成本，复用服务，减少无效的工作时间，重复的劳动等问题；这才是员工之于企业的价值所在，有了价值，才会有发展。

技术是解决问题的手段，而不是目的。个人与企业共同成长这才不会辜负自己的努力，也是健康的职业生涯。