浅谈微服务架构

微服务架构是一种架构理念。旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。从而降低系统的耦合性，并提供更加灵活的服务支持。

谈到微服务架构避免要说下时下流行的中台架构，由于前台系统直接面向用户，为适应不断变化的现实情况，前台系统时常需要调整。但后台系统由于直接面向数据，保持稳定是后台系统的重要目标。为了解决前台和后台系统之间的这种矛盾而引入中台系统。在此基础上提供了中台架构，就是把一些业务或者技术上的共性东西提取出来，沉淀到中台端。把共性沉淀下来，形成了业务中台，把技术共性沉淀下来，形成了技术中台。

谈到微服务架构离不开微服务，如何划分微服务的边界成了架构师的首要考虑的问题，边界面过大，就成了单体应用，过小，让整个系统变得非常复杂。领域驱动设计能够更好切分微服务的边界。

1.   领域模型是对具有某个边界的领域的一个抽象，反映了领域内用户业务需求的本质；领域模型是有边界的，只反应了我们在领域内所关注的部分；

     2.   领域模型只反映业务，和任何技术实现无关；领域模型不仅能反映领域中的一些实体概念，如货物，书本，应聘记录，地址，等；还能反映领域中的一些过程概念，如资金转账，等；

     3.   领域模型确保了我们的软件的业务逻辑都在一个模型中，都在一个地方；这样对提高软件的可维护性，业务可理解性以及可重用性方面都有很好的帮助；

     4.   领域模型能够帮助开发人员相对平滑地将领域知识转化为软件构造；

     5.  领域模型贯穿软件分析、设计，以及开发的整个过程；领域专家、设计人员、开发人员通过领域模型进行交流，彼此共享知识与信息；因为大家面向的都是同一个模型，所以可以防止需求走样，可以让软件设计开发人员做出来的软件真正满足需求；

     6.  要建立正确的领域模型并不简单，需要领域专家、设计、开发人员积极沟通共同努力，然后才能使大家对领域的认识不断深入，从而不断细化和完善领域模型；

     7.  为了让领域模型看的见，我们需要用一些方法来表示它；图是表达领域模型最常用的方式，但不是唯一的表达方式，代码或文字描述也能表达领域模型；

     8.  领域模型是整个软件的核心，是软件中最有价值和最具竞争力的部分；设计足够精良且符合业务需求的领域模型能够更快速的响应需求变化；

在进行微服务设计与开发过程中需要遵从组件设计原则，最终达到微服务内部实现高内聚，低耦合。

复用/发布等同原则，软件复用的最小粒度应等同于其发布的最小粒度。

共同闭包原则，应该将那些会同时修改，并且为相同目的而修改的类放到同一组件中。而将不会同时修改，并且不会为了相同目的而修改的那些类放到不同的组件中。

共同复用原则。不要强迫一个组件的用户依赖他们不需要的东西。不是紧密相连的类不应该被放在同一个组件里。

无依赖环原则：组件依赖关系图中不应该出现环。

稳定依赖原则： 依赖关系必须要指向更稳定的方向。

稳定抽象原则： 一个组件的抽象化程度应该与其稳定性保存一致。