微服务与领域驱动设计，架构实践总结 _交易

文章图片

\">
怎样的架构才能配得上造到飞起的变化？

一、软件复杂性1、复杂原因如果软件系统存在持续的迭代周期，那么其中业务、技术、架构的复杂性都会直线拉升，其相应的开发难度也会提高，可以用一句话总结其根本原因：唯一不变的就是变化；

业务变化：导致复杂性的根本原因，在多端口多版本适配的过程中代码快速膨胀；
数据变化：数据随着业务的变化和发展，不断沉淀积累，需要做横向与纵向的管理；
技术升级：技术组件可能因为漏洞，或者更好地解决问题，不间断升级版本；
人员变动：模块的开发人员一旦出现流动，换人接手会给代码带来风格上的差异；
心态起伏：持续应对复杂问题，但平稳的心态很难持续，也是人员流动的一个因素；

应对复杂的变化一直都是软件工程的核心难点问题，如何用较小的架构变化应对较大的业务变化，就是设计中常说的：高内聚、低耦合；还需要补充很重要的一点：单从技术层面是无法持续解决复杂问题的，还需要从管理角度去定义流程标准，规范各种解决方案，是整个部门要持续面对的事项。
2、应对复杂不管是常说的设计模式、原则、面向对象，还是架构中常用的集群、微服务、领域驱动等，都是在寻求更合理的方案来应对业务的变化；但是没有一劳永逸的解决方法，既要做一定前瞻性的设计去预期业务，同时还要避免过度的设计影响业务进度；这就需要研发团队具备一定的业务高度和技术深度：

在系统落地的过程中，需要对业务深入的分析和理解，不断优化技术层面的解决方案；比如微服务的思想是通过拆分的手段实现业务块之间的低耦合，领域驱动设计则实现各个业务逻辑的高内聚；下面围绕两种方式的实践去详细分析。
二、微服务架构1、架构设计系统的架构设计是一件极度复杂的事情，在工作的这几年大致经历过如下几个阶段：单服务、多服务集群、微服务、持续集成；在近2年比较稳定的选型是微服务+自动化集成的模式：

思考其本质的变化逻辑，即为了应对更复杂的业务体系；不管是业务拆分还是模型设计，都是在不断实现高内聚低耦合的原则；降低业务之间的关联影响，分离业务和技术的高度耦合。
2、业务场景这里先来看一个经典的业务场景：电商交易；基于微服务架构的电商交易场景中，通常至少会涉及如下几个核心服务：交易、账户、订单、商品、仓储、物流；

站在业务角度，进行模块化拆分和管理，结合持续集成的组件，通常可以轻松地应对各种复杂的业务场景，但是不存在真正意义上一劳永逸的手段，业务变化带来的各种问题总会无脑推动开发去寻找更合理的解决方案；

在一次完整的电商交易场景中，实际上真正涉及到的微服务远不止图中的几个，在Trade服务中交织关联多个其他服务，在MVC的分层管理下，初期并不会存在较大风险，但是业务一旦经过多版升级改造之后，并且还存在版本兼容的要求，会给人一种极度混乱和不踏实的感觉；