从软件的生命周期看架构设计以及微服务架构的形式与特点

从软件的生命周期看架构设计

可以把这些阶段概括为3个大的周期:设计期(包括立项、计划、技术选型与方案等)、实现期(包括开发、测试、发布、实施等)、运行期(或维护期，包括修复bug、 新增功能、多版本维护等)。

 

1.设计期

在设计期，软件作为一个成品还不存在，所以我们可以称之为概念形态。此时架构师、产品经理或需求分析师等人员利用自己的经验和能力，对系统的业务需求进行分析、拆解、抽象，对系统的非功能性需求进行分析，形成业务文档和技术文档，以及技术验证代码等。这个阶段，架构设计工作是重中之重，其中包括:

• 系统拆分， 如何把系统拆解为不同的子系统、模块、业务单元;
• 技术选型，使用什么样的基础技术框架或脚手架;
• 技术验证，确定核心技术难点如何解决，检验能否满足期望指标:
• 接口规范，系统内部的不同部分以何种形式确定接口契约和数据通信方式;
• 集成方式，系统与外部其他业务系统如何进行集成;
• 技术规范，如何规范开发、测试、部署和运维的技术标准性;
• 部署方案，系统如何进行物理部署，需要多少台机器、什么配置，对网络有什么要求:
• 运维方案，系统如何进行技术性运维，如何实现日常监控、预警报警;
• ........

这个阶段总结一下就是:需求导向，架构先行(包括业务架构和技术架构)。很多项目因为前期的设计阶段考虑得不够充分，导致在开发和运行期出现大量问题。

2.实现期

这个阶段主要是编码与测试，为部署上线做好准备，是软件从设计到最终的生产系统的过程，我们可以称之为代码形态。此阶段需要考虑的技术类工作如下:

确保各项技术规范和技术指标的执行落地，保障高质量的代码:

指导研发人员和解决各类技术问题，提升研发团队效率;

制定测试的技术性方案和基准，包括自动化、性能、安全等方面:

配合准备部署环境，运维实施方案落地等:

实现期的主要任务是大量软件工程师根据设计期的设计进行编码。大量的技术人员，大家背景不同，知识储备不同，编程水平和习惯不同，努力程度不同。如何让所有工程师既能够按数量保障项目进度，又能够按质量保障软件品质呢?秘诀就在于:技术标准的精确统一，系统部件的良好拆分，此外最好有适合于此类项目的脚手架，随时能解决各位技术难点问题的“救火队”。系统部件的良好拆分，保障了任务可以拆散成一个个的小单元，分发给不同的开发者。

技术标准的精确统一，可以实现不同个体的产出物最大程度的一致性。

这个时期因为业务调整或技术问题，可能会对架构设计的一些细节进行小范围的调整，以适应实际项目的建设需要。在这个过程中，同时需要根据实际变化，对现有的设计文档进行同步调整，以便精确地描述系统的状态及变化。

3.运行期

这个阶段系统上线、验收通过，已经初步稳定，然后开始进入维护阶段，成为设计期架构设计草图的一一个可用实例，我们可以称之为实例形态。此时需要考虑:

发布上线相关基础性工作，包括是否使用持续集成(CI) 、自动化发布等技术:

运维基础性工作， 自动化运维、监控等相关技术:

特别是发布与运维工作，一般要作为整个研发团队的通用性基础设施来考虑。不同的业务线或系统，可以复用一套基础设施来服务于生产环境。进入维护期后，软件系统日常通过内外部用户反馈的问题和改进意见，不时需要修改代码发布补丁版本，或者调整配置以满足用户需要。经过较长一段时间，业务模式和内外部环境发生了比较大的变化后，系统简单的补丁维护可能已无法满足用户需求，需要大范围地添加新功能和修改旧功能的逻辑流程。此时就可以成立专门的团队，重复上面的步骤，基于现有系统重新做一些改造性的设计重构(设计期)，再编码实现(实现期)，最终发布一个较大的版本(运行期)。

在软件的整个生命周期里，架构师(或架构组)是一个项目或产品线的技术负责人。再大一点的组织，比如公司或研发中心级别层面也许还有架构部。架构师、架构组、架构部在不同层面对自已工作涉及的所有技术问题负责。其实上面罗列的这些工作汇总一下，再加上技术规划与执行落地、技术人才的选拔与培养等，可以作为项目组架构师或研发团队架构组的工作职责。

 架构的形式与特点

架构以文档和代码呈现

我们一般说的架构既包括架构的设计过程，又包括设计的产出物，可以是各类设计文档、设计图，也可以是一-些技术验证代码、Demo或其他相关程序。文档的目的在于准确记录我们的思维产物，在软件尚未实现时，作为指导蓝图，尽量精确地描述清楚软件。在软件的实现过程中，可能随着我们的深入研究，根据具体情况对文档做出局部的调整和修改。该软件已经实现以后，部署运行的软件实例和代码只能说明软件目前是什么状态，却无法告诉我们这个软件系统是如何从开始设计，慢慢变成现在看到的样子的，这个思维的过程和中间做出的很多决策的信息丢失了。一个软件系统的长期稳定发展，必然需要-一个可靠的、随着软件本身的维护不断同步更新的文档作为每次变更的出发点。这样我们可以随时沿着架构相关的文档逆流而上，了解这个软件系统从整体到具体的设计思路。同时，文档作为结项或交接的一部分，也是整个软件项目的产出物的一部分，成为公司IT资产的有机组成部分。

其中一个架构图的例子如图1-3所示。

文档是设计的载体，代码是系统功能实现的载体，技术和业务最终都有很大一部分体现在代码里(技术的另外--部分是部署运维，即如何最终把这些代码应用到设备上;业务的另外一部分是操作流程，即如何应用到系统与人的交互上)。广义上来说，代码和代码里的注释都可以认为是文档的一部分。技术社区有一种观点:结构良好的、可读性强的代码，是最好的“文档”。

 

那么怎么才能写出好的代码呢?关键在于两个词:经验、重构。GoF的23个设计模式是在面向接口的编程环境中，处理一些常见问题的代码编写经验。通过灵活应用这些模式，我们就可以在处理各种一般问题时进行抽象和总结，进而写出结构良好、可读性强，并具有一些灵活性的代码。如果是面向企业应用领域的系统，那么企业应用架构模式可以供我们参考。如果是面向多个系统的集成领域，那么企业集成模式和各种中间件可以帮助我们更好地处理问题。

技术性工作里存在一个“一万小时理论”:在-一个领域里需要持续实践一万个小时，才可能成为该领域的专家。编程也是一个这样的领域，随着我们代码写得越来越多，维护性的代码改得越来越多，我们就能总结和沉淀出很多经验，变成自己的编码风格和习惯。在这个过程中通过实践和思考，不断地提升和发展自己的技能，进而反馈到代码中，我们可以认识到以前代码的不合理之处，不断地重构和改善既有的设计与实现。

从代码里，我们可以很直观地了解到，程序做了什么、不能做到什么、能做到什么程度，以及其与相关的文档(包括业务文档和技术文档)是否一致。但是代码不适合作为唯- -的“文档”，只有代码没有其他文档，就像是一部只有结尾没有开头和过程的电影。我们只能了解这个系统的一个时间点的切面影像。所以，在设计类文档和代码注释里，很多时候描述清楚为什么(Why)和怎么样(How)比单纯描述是什么(What)重要得多。一个具体问题的技术选型，实现一个业务模块的某个具体功能点，其实都是在做技术相关的选择(Choice) ，而我们做一个技术选择的时候需要考虑:我们面临的问题是什么，有几种可行的方案，各有什么优势和劣势，选择哪个方案最适合目前的形势，并可以兼顾一下未来一段时期的发展，等等。如果我们没有留下来任何思考的痕迹，那么这些思想过程的智慧就会在软件的创造过程中丢失。随着时间的流逝，我们只能看到系统最终的样子。这种信息缺失对于目前大规模软件开发的协作过程非常不利。例如，我们看到一个8年前的遗留系统里，有一“坨”代码非常烂。我们改了一下，过段时间发现运行不正常了，回过头来再细细分析，发现业务逻辑需要优化，框架也需要调整，不然这个地方的代码会很别扭。很多时候，我们要是直接能看到以前文档描述了当时做的选择和权衡，就可以避免很多的“坑”，降低很多沟通成本，特别是涉及团队成员的变动和跨团队的协调成本。一般的知名开源项目(比如Apache里的各个活跃项目)，都会在讨论组里进行技术选择的讨论，并以帖子和回复的方式，进行问题讨论的发起、提案、阐述、投票，最终确定其中的某个处理办法。这样大家既达成了一致，也留下了所有的思考和辩论痕迹。

2.架构服务于业务

正如十九世纪的伟大建筑师路易斯●沙利文(Louis Sullivan) 倡导的建筑设计著名格言:“功能决定形式(Form follows function) ”，软件架构首先要服务于业务功能。设计一栋大楼不管美不美观、大气不大气，首先需要考虑的是这栋大楼是做什么用的，是要开一个百货公司，还是一个跨国集团的总部大楼，还是当地市政府的办公大楼。同理，架构首先也需要对业务负责。而业务并非总是一成不变的， 随着市场环境的变化、用户习惯的变化、竞争格局的变化，业务形态也一直在顺应环境而改变。架构设计也需要考虑系统在未来一段时间内能支撑这种调整，并且在满足业务需求和一定的前瞻性的基础上，综合考虑成本、周期、效率、速度、风险等因素。

3.架构影响研发团队的组织形式

业务拆分的方法和技术框架的选择必然会影响研发团队的组织形式。业务拆分得越细致，越有利于我们更好地对项目的各项指标进行量化和计算，更精确地估计工时和成本，从而指导每个小组应该分配多少资源，使用什么样的协同和任务确认形式。随着项目的推进，计划与实际情况之间的匹配程度也可以随时进一步 精确调整，进而我们应该对每一块任 务的投入资源进行动态调整。技术框架的选择也-样，选择最合适的框架，比如对于Web系统采用最大众化的SSH或SSM,既有利于我们迅速找到合适的程序员组成新的研发团队，也因为比较成熟、“坑”比较少，可以在开发过程中避免很多问题，节省一些填“坑”的时间:针对一个具体的业务领域，采用一个功能很强、场景很贴近、较新的技术，则需要找到一些熟悉这些技术的人，或者培养几个人，这就增加了时间成本或人力成本。

反过来，研发组织的结构和成熟度也会对我们最终所采取的技术架构产生重要的影响。比如，一个由3个初级程序员组成的创业小团队，就不适合采取特别复杂且小众的开发框架。相反的，利用快速开发框架或脚手架把产品设计迅速实现应该是团队的核心诉求，所以某种全栈类的全家桶解决方案可能才是最适合的技术选择。以前我(本章作者)带的一个新组建的初级前端程序员团队就有类似问题，团队成员一直关注于各个美轮美奂的具体UI组件，这些组件可能是不同的技术框架衍生出来的。而我们要做的是-一个业务系统的后台，炫酷的UI不是重点，组件较全、方便易用、有大量的案例，少量定制需求可以自行解决，这些才是更重要的关注点。注意到这个情况以后，我立即调整了团队的技术方向，选择了目前最流行的一个前端框架作为解决方案，最终取得了不错的成效。

4.架构存在于每一个系统

每一个已经实现并运行的系统，都是特定架构设计的载体。有些系统对应的架构，有详细的设计文档:有些系统的设计文档残缺不全，甚至还因为在系统发展变化的同时，文档没有更新，导致设计文档与实际系统不符:有些系统干脆就没有设计文档。但这些系统都是基于- -定的架构来创建的。就像是优秀的老工匠，制作瓷器之前可能并不会把形状规格画到图纸上，但也能做出来一个漂亮的陶瓷花瓶。因为所有的设计细节，哪个地方需要上釉，都在老工匠的脑子里。可是这种没有显式设计的“脑内架构”方式，明显有很多缺点，例如，不能大规模进行工程化方式处理，老工匠无法通过讲述自己的想法就让学徒也做出一个同样尺寸规格的花瓶，甚至老工匠自己也无法精确复制自己的上一个作品。

5.每种架构都有特定的架构风格

每种架构方式、每个具体系统内所体现的架构设计，都可以被工程师理解，进而提炼出一些架构思想和设计原则，这些思想和原则就是这种架构方式的风格。依据这些风格，我们可以将各种架构方式分门别类，从而进一步讨 论每种架构风格的特点。例如，在实现期的代码形式中，系统由各个相似的类库(作为组件)构成，在运行期这些组件又同时在同一个进程中，这时我们可以认为这是一种“组件式单体架构风格”。

6.架构需要不断地发展演进

随着计算机软硬件的不断发展，软件架构思想也在不断地发展变化。另一方面，软件为其提供业务处理和服务能力的每个具体行业领域也在不断发展变化，业务处理流程和业务形式不断地推陈出新。这就要求我们在系统架构设计时，保持终生学习的精神，持续吸收新思想、新知识，贴近一线业务群体，随时因地制宜，调整架构设计，采取最适合当下场景的解决方案。同时对于存量旧系统的维护与改造，很多时候无法一次完成目标，可以考虑循序渐进，设定几个大的里程碑，逐步推进，最终实现比较理想的架构设计。6年前，我在阿里负责一个遗留系统的重构，40 多万行代码，没有人清楚地了解项目是什么情况，也没有一篇文档。4个架构师“小黑屋”封闭开发，先自己摸爬滚打搞清楚需求，然后采用“分布式服务化+灰度发布”的办法，先拆出来并重新实现搜索系统，再拆出来订单系统，最后“搞定”产品系统。做重构的同时还承接新的需求，经过了几个月的改造，代码减少了一半，性能提升了几十倍，成功抗住了当年的“双11”活动，并且培养了几个能完全掌握这个新系统的核心研发人员。这个过程对我影响最深的一-点就是:循序渐进，终达目标。特别是在具体的设计实践中，思路和方法，比结论更重要。一个正确的结论在别处可能就是错的，但思路和方法是可以复用的。