架构师训练营 - 第十周作业



作业一：

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



时序图：





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



系统的初期，为了快速的上线业务，快速试错，大多数小型的公司其实更多的是采用一种单体的架构，这种架构易维护开发，成本比较低，但当随着业务的发展，用户量的快速发展，可能架构会随着进行变化，从原来的单体架构演变成前后端分离的架构，同时可以大量的使用缓存，分库分表，异步对系统进行优化，使系统能够承载更大的用户量。但随着公司的进一步发展，业务越来越服务，用户量达到上亿级别，单纯的前后端分离架构已不能满足业务的多样性和复用，可能会出现重复造轮子，开发成本高的问题，这时候微服务架构就应运而生了。微服务架构是把双刃剑，很香但成本也很高，但一个业务拆分成越来越多的微服务模块，带来的可能是运维监控的复杂性，甚至说性能的下降(服务之间的调用需要走网络调用)。并且，微服务的拆分其实很考验对业务的熟悉，按什么粒度去拆分业务服务，才能达到更高的高内聚，不至于为了微服务而微服务，最后造成大量不必要的服务间调用，降低性能，那就得不偿失了。以上，我对微服务的一点见解，总的来说说，微服务应该是业务到达一定规模和复杂度的一种产物，在选择微服务架构的时候，应该多去考量，是否自己的业务已经发展到这种程度或者预期能发展到这种程度，技术很多时候是服务于业务，业务发展的更好，技术才能去驱动业务，而不要为了技术而技术。