架构设计5步曲

       狭义上的架构设计过程就是“分+合”的过程，一个系统=架构元素+架构+整合机制。那么怎么切，依据什么切？切了以后怎么往一起整合？我们这里做个简单的介绍。    

       架构设计大的步骤：理清楚要建设的系统的环境上下文要求和需求、梳理出关键核心问题、根据核心问题定义边界、根据边界切分架构元素（子系统、模块、服务、类）、定义架构元素之间的交互机制。一共5个步骤，按照这5个步骤进行分析设计，我们基本上可以做到八九不离十。下边我们逐个讲解每个步骤。      

       第1步：理清楚要建设的系统的环境上下文要求和需求，这一步讲究“全面性”，这一步需要架构师有“系统思考”的能力，从空间和时间上对整个系统有个全面的理解。我们之前很多项目出现延期、推倒重来、设计不合理等问题，最重要的原因之一就是获得的需求不够全面；很多时候，架构师和开发会把注意力完全放在需求文档上。作为某个模块和功能点的开发人员，这个可能就够了，但是如果是架构师就远远不够。因为这些系统环境上下文要求和需求都是下边第2步里“关键核心问题”的来源。如果环境上下文要求和需求收集地不够全面，可能影响到“关键核心问题”的梳理，最终影响到架构设计。环境上下文要求包括以下内容：     客户系统部署环境要求：比如说客户的特殊机房、网络安全机制要求，这些会影响架构中关于通讯机制的部分和物理部署；再比如说我们需要建设的系统需要和客户已有的系统进行整合，使用同一套用户体系，这个会影响到我们用户注册、授权、鉴权机制；     客户工期的要求：1）如果工期要求短，我们可能就需要设计出相对简单易于实现的架构。2）为了加快工期，团队可能需要投入大量的研发资源，因此我们在切分架构的子系统、模块、服务的时候就要保证适合大军团并行作战，各自互不影响，而且他们所负责的联调、整合机制要简单、高效。而不能让模块之间界限不清，耦合复杂，这样研发任务也不好切分，形成瓶颈，即使有资源也难以介入；3）这个架构要让研发流程的后续环节提前介入，并行进行，比如说可以让测试尽早介入，缩短后续环节的流程，这就要求保证设计的架构要可以做到针对架构元素这种细颗粒度的“可测试性”，比如针对某个组件或者服务进行测试；     分期上线的要求：架构师要有全局视野，是属于团队中那个需要抬头看路的人。因此，务必要关注客户的短期建设目标和长期建设目标。比如说用户第一期先上PC端的建设工程，二期再上PC端的政府采购，三期再上建设工程和政府采购的APP项目。那么这个时候，我们至少考虑：1）二期上线的政府采购不要影响一期的建设工程项目，比如说不要影响已上线系统的旧数据，这个时候我们可能就要让一期和二期的系统作为独立的子系统，可以独立部署，各自是各自的数据库。同时，为了提高用户体验，不能让用户注册两套账号，分别登陆两个系统进行工作。所以要提前想好整合方案，比如SSO等等；2）我们需要精心设计后端边缘服务，保证一套边缘服务可以同时支持PC端和APP端，而不是开发两套边缘服务。因为两套边缘服务不但带来额外的开发工作量，随之而来会引入测试、运维的额外工作。也就是说，在分析和设计架构的时候，不要过于计较一城一池之得失的短期利益，而是要全局利益最大化。当然了，这个需要架构师根据具体问题去平衡，基本指导原则是死的，架构师是活的，审时度势和平衡就是架构师的本职工作和价值之所在；       规避风险要求：风险是相对的，不可能没有风险，在架构设计过程中规避风险也是需要重点考虑的问题之一。比如：1）技术风险，我们对新技术的都需要一个循序渐进的过程，对于新的技术带来的风险，我们需要有预备方案，从架构的角度来讲，需要有规避机制。比如说我们引入一种新的通信机制，那么我们就需要抽提出接口组件、基于具体通讯机制的实现组件，保证系统的其他部分依赖于接口组件，而不关心具体的实现组件。保证这个实现组件可替换、可以独立研发。这样就可以让技术好的研发人员集中攻关，而且一旦失败可以有替换方案补位。2）人员风险，如果团队中顶尖研发人员分布不够均匀，可以通过架构切分，把一些复杂度集中在某些模块，以此来降低其他模块的复杂性。相反，如果团队中实力较强的研发人员分布比较均匀，架构设计的时候就可以把复杂性稀释到每个模块，防止局部复杂性出现，因为复杂性过于集中，就会形成“高地”，会增加对研发人员能力的要求，这样往往会成为瓶颈。     任务计划要求：系统的功能一般都会有主次先后，在拆分和排布任务的时候，一些核心的任务，比如说和其他模块交互比较多的模块、或者其他模块都必须依赖的模块、有风险的模块都是需要放在任务计划比较靠前的位置，以减少研发进度“瓶颈”的出现，或者“风险前移”。另外，要根据任务的难易程度进行切分，以配合团队人员能力层次结构进行任务分配。       联调和测试要求：有的模块需要调用第三方服务，比如说和第三方的软件硬件对接。而且这个硬件有特殊的部署环境要求，我们需要去现场联调。我们就需要把这部分联调的工作单独抽取成子系统、组件、服务。这个组件不需要关心其他的核心业务，也可以交给专人处理。这样测试和联调起来很简单、而且每次联调不需要带其依赖该功能的相关人员去现场。只要把负责这个模块的人派过去，只关心这部分功能的联调。如此就能节约联调和测试资源，提高效率。而且往往一个架构元素不可单独测试，可能边界划分就存在问题；       功能性需求：这里就不多做说明，架构师需要注意辅助产品经理和需求梳理出一些隐藏需求就可以了；非功能需求：比如界面美观程度、相应速度、可伸缩性、可用性、鲁棒性、安全性、容灾能力、可扩展性、可监控性、可维护性等等，这里不做赘述，大家可以根据每个系统的要求作出全面评估和考虑。    

        第2步：梳理关键核心问题，这一步架构师需要经过“平衡”，紧抓”主要矛盾“，而不是“胡子眉毛一把抓”。架构关注的是主要的、核心的、对整体影响较大的问题，比如说：某几个功能可以拼成一个系统单独运行和出售、比如说场地系统里的“门禁卡”功能需要支持对接多家厂商、比如说客户已经有了用户中心，我们的系统需要和这个用户中心进行整合......这些都是可能决定系统成败的因素，或者说是一旦出问题，影响面非常大的问题。架构不关心那些琐碎的、局部的、影响比较小问题，比如说某个按钮的展示风格、完成某个功能需要几次请求、某个功能的实现需要分解成几个函数......这种问题即使搞砸了，也不会波及到其他功能从而动摇系统的根本机制。架构师需要从第1步所收集的问题中，萃取和分离出核心的问题。    另外这里注意的是，这些问题拿来后不是直接就作为第3步的输入。有的问题可能需要通过分解、抽提、映射转换、合并同类项等办法剥离出真正的问题，甚至会返回去影响需求的重新设计。经过这些步骤后再进行第3步的工作。比如我们会挖掘出一些隐性的需求和问题，而这些问题可能只靠需求人员或者产品经理无法分析出来，比如因为特殊的部署环境要求，为了提高部署效率，需要开发出一个部署系统。再比如说，竞价系统本身是一个独立的系统，但是某一天业务提出这样一个需求：如果没有人参与竞价，默认指定第一个缴纳保证金的人为竞得人。如果说我们不加分析，直接去实现就会发现，竞价系统的边界被破坏了，竞价系统需要依赖保证金系统的服务去获取第一个缴纳保证金的人的数据。如果我们就此引入对保证金的依赖，天长日久，竞价系统将变成一堆异常复杂，难以复用的垃圾。经过和需求一起分析后，我们立足于竞价系统的概念边界，提出一个新的概念叫做：默认竞得人。业务系统每次推送数据的时候，只需要把默认竞得人的数据推过来就行了。这样我们做到了“一石二鸟”，保证了竞价系统的独立性、丰富了竞价系统的概念和功能。这一步需要考验架构师的“深度思考能力”、“抽象思维能力“。      

        第3步：根据问题定义边界；      边界的定义，就是定义切分的维度，这个维度就从第2步中梳理出来的关键问题入手。比如说：要解决场地系统和多家门禁厂商的支持。我们就需要按照这个问题划边界。切分成两个部分，一个是门禁的接口组件、一个是门禁的实现组件。接口组件被其他业务功能依赖，其他功能不关心底层用的门禁技术到底是哪家。门禁实现组件，会有多个，按照每家厂商一个实现组件来切分，这样我们就形成了一个门禁适配组件集。客户采购了哪家厂商的门禁产品，我们就把对应的门禁实现组件加入到系统中。这样，我们可能把研发、联调、测试的时间都省去了。而且，随后要接入新的厂商，我们只需要针对这个厂商开发一个新的组件就行了，而且不影响之前已有的组件，哪些组件不需要再测试，联调一遍。这一步需要考察架构师的“抽象思维能力”和对“面向对象设计原则”的理解能力，比如这个例子就使用了“依赖导致原则”、”开闭口原则“。      

       第4步：根据边界切分架构元素（子系统、模块、服务）；边界切分的元素到底是采用子系统、模块、服务哪种呢？这个仍然要根据边界而定，这个边界是要解决的问题属于哪个颗粒度。比如：某些功能点要支持单独售卖和部署，这个时候切分的边界就是系统级边界，就要先采用子系统切分的机制；如果这个功能需要支持多加门禁厂商，这个时候按照组件进行切分就可以了；如果我们要解决某个功能点的横向扩展能力，支持高并发访问，这样就需要切分成单独的微服务；这个视具体问题而定，不一而足。这一步需要架构师对业务和技术都有较深的功底，能够针对不同的要求匹配出合适的技术。      

       第5步：定义架构元素之间的交互机制；切分好后需要将各个架构元素整合在一起，这样才能完成一些完整的、有意义的业务。比如说系统之间可以采用Web Service、分布式消息、微服务、数据库、分布式缓存来作为交互的机制。而系统之内的组件之间，则可以采用普通服务接口的方式进行解决，而没有必要采用更加复杂和“高大上”的微服务。如果是类和类之间，采用Spring这种Bean管理容器就可以解决。这一步要考察的能力和第4步是一样的。     根据以上的步骤，我们由粗到细、层层递进，就像推理数学题一样把框架推理出来，保证每一个决定和步骤都有据可循，而不是凭经验、凭本能、毫无根据地拍脑袋拍出来。