架构师训练营第一期第十周作业

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

微服务如今已经是一个很大的话题，微服务的思想依旧是由于单体应用随着业务内容的增加，在开发，部署维护都越来越困难的情况下自然而然的产物，因为拆分，化简问题是解决复杂的最基本也是最有效的思想，单随着拆分之后的系统也越来越复杂的时候，就需要总结出一些更好的理论来指导拆分的过程，由此，领域驱动设计，组件设计原则，中台架构在探索的过程之中脱颖而出。

在最初的单体应用之中，我们通过代码分层，代码结构，命名空间，这些代码技术来把业务之间的关系通过模块隔离起来模块之间相互引用来解决不同模块的调用，通过注入依赖来解藕不同模块之间的直接调用，无论多么复杂的业务，如果是微小行的团队，这样的架构都够用。完全可以不需要引入微服务架构，因为这样的架构一样可以使用领域驱动来设计，隔离不同模块的边界，或者通过组件设计原则，划分出边界清晰的组件。

但是如果是多个团队之间的协同开发，就需要将模块从单体应用拆分成多个更细致的单体应用，来解决这些模块或者叫做服务可以并行开发，独立发布，减少开发冲突的问题。这种由于人员结构被迫的拆分，对业务的边界划分要求更加严格，否则就会引起混乱，因为单体应用即使划分的混乱，依旧是在一个应用之内，有有限的几个掌握项目知识的人去协调开发，这种协调相对于跨团队来说还是容易的多。而多个团队协作开发，没有团队能够掌握完整的项目知识，其他团队的变更不可能全部了解，就需要有这样的一种机制，使得服务之间的依赖尽可能的少的了解服务的相关知识，也能保证使用这个服务使用的正确，整个业务流程能够顺利的完成。

对于无状态的服务，只要解决服务之间调用的拓扑结构的问题就可以在开发微服务架构上调用其他服务，如同调用内部模块一样简单，因此诞生了，服务注册，服务发现，服务网络，RPC架构这些决绝问题的方式。但是对于有有状态的服务，设计到状态的持久化，问题就变得复杂了，面对众多的服务，什么状态改由那个服务来负责持久化，就使得问题变得复杂，如果所有服务都指向同一个数据库，也只是代码层面的隔离，如果是分表分库，事务的问题就需要通过，CQERS，事件溯源等手段来解决，因此这些微服务相关技术的诞生也是为了解决微服务相对于单体服务而带来的问题创造出来的。

因此无论选择用什么技术实现微服务架构，无论使用中台与否，或者是使用领域驱动设计都是以自己公司的业务需求，人员配置，技术水平为基础去解决问题，解决问题的过程，技术选型，架构设计永远不可能一次性到位，随着业务的变化，人员结构的变化，要解决的问题，和怎么解决问题，都在变化，微服务的服务划分，服务的颗粒度，都不是固定不变的。各种已有的解决问题的方案只是手中的工具，是不是用，用那个工具，才是真正需要智慧的地方。