显卡|微服务与领域驱动设计，架构实践总结游戏主机|机箱|雷神|数码

文章图片

文章图片

文章图片

文章图片

文章图片

文章图片

文章图片

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

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

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

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

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

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