“ 分享软件系统架构设计要解决什么问题，好的设计是怎么来的和一些非互联网架构的设计样例。”





我在《为什么每个软件人都要懂点系统架构？》里提到，每个软件人都要懂点系统架构。这篇文章将明确告诉大家，即使是小白也可以学习做架构设计。我将分享架构设计要解决什么问题，好的设计是怎么来的和一些非互联网架构的设计样例。



01 要解决什么问题



要回答这个问题，首先要明确架构设计是什么。我就不抄网上的标准答案了。下面我通过4W1H来分享我的理解，更便于小白理解：



What：网络、服务器、存储、中间件、数据库等硬件资源的搭配；



Why：系统在生产环境上能满足非功能性需求，确保服务连续性，并确保在极端情况下能在规定时间内恢复业务；



Who：架构设计师、系统设计师和系统负责人共同配合；



When：收集到系统非功能需求后，获取硬件资源之前；



How：

1. 确定业务重要性；

2. 收集非功能性需求；

3. 架构设计；

4. 设计评审；

5. 获取硬件资源。



02 好的设计是怎么来的？



确定业务重要性



由于不同系统所服务的业务的重要性是不一样的，通常采用恢复时间目标（Recovery Time Objective，RTO）来确定，也就是该业务可以允许系统服务中断最长的时间有多长。



对于业务和用户来说，当然希望系统服务完全无中断，但是要实现完全无中断，所需要的架构成本会非常高，这个成本不光是首次采购服务器的建设成本，还有系统将来运行过程中，所有服务器的运行和维护成本。所以，架构设计不求“最好”，只求最合适。在每个项目立项时或系统开发前，业务都需要评估他们的RTO，然后架构设计师选择与RTO匹配的设计。



比如，最重要的业务，不允许任何服务中断的，其RTO就是0，在架构设计上必须采纳同机房内服务器的“双活”或“多活”，机房间的灾备方案也应该是“双活”或能实现自动的故障切换，机房间的数据是完全同步的，实现单台服务器故障或机房间的切换对业务影响最低。当然，这套方案的成本最高。



如果业务的RTO是4个小时，也就是允许系统服务中断时间最长的时间不超过4个小时，在架构设计上可以采纳同机房内服务器的故障切换，机房间的灾备方案可以是“双活”或自动的故障切换。如果业务的RTO是8个小时，在架构设计上可以采纳同机房内的故障切换，机房间的灾备设计可以是手动的故障切换。



收集非功能性需求



这里主要围绕着系统所需要支撑的业务量、并发用户数、系统响应要求，以及未来可预见的业务量和用户数的增长，确定硬件配置方案。CPU配置可以参考SPEC值，也就是“跑分”。



如果是现有硬件因业务增长而升级，需要收集现有硬件各种运行指标，如CPU、内存、存储等的使用情况，来确定当前负载，并以此为基础推算升级后的硬件指标。



架构设计



就是画图了。



业务与用户都期望IT系统的服务是连续的，不会因故障而中断服务。要满足这一要求，在架构设计上，必须考虑避免单点故障导致整个系统的服务中断，也就是鸡蛋不能放在一个篮子里的道理。可以想象，如果一个IT系统只部署在一台服务器上，那么只要这台服务器出现故障，服务就会中断。



应对这种情况，有两种方案：



故障转移（Failover）——把系统部署到两台服务器，其中一台服务器是主服务器，所有用户请求默认发到这台服务器；另一台服务器是备用服务器。一旦主服务器出现故障，所有用户请求切换到备用服务器，继续提供服务，为修复主服务器故障争取时间。



双活或多活（onsite resilience）——把系统部署到两台服务器，并把用户的请求均衡地分配给这两台服务器分别处理，那么不光系统的处理能力提升了，而且即使其中一台服务器出现故障，另一台服务器依然可以支撑服务，处理用户请求，这种设计叫“双活”。如果是通过多台服务器来实现这种设计，就叫“多活”。



这两套方案均可避免单点故障，但成本是不一样的。在故障转移方案中，备用服务器是应急用的，其配置可以低于主服务器，而在“双活”和“多活”的方案中，所有服务器的配置应该一致，所以从成本上看，故障转移 < 双活 < 多活。同等服务器配置的情况下，从业务处理能力上看，多活 > 双活 > 故障转移。所以，采取何种方案，需要结合业务的关键程度、性能要求、成本等综合考虑。



以上是从服务器的角度来考虑的。放置服务器的机房也会出现故障，比如当地震、海啸、水灾、火灾、断电、雷击等灾难发生时，可能会出现整个机房无法工作的情况，从而导致企业的所有IT系统无法提供服务。要避免这种情况，很多企业都会建设灾备机房，这也是监管机构对某些行业的硬性要求。



对于灾备机房，一般要求“同城异地”，也就是主机房和灾备机房在同一城市的不同地点，需要有一定的物理距离。更高的要求有“两地三中心”，也就是在“同城异地”的基础上，还需要在另外一座城市配置一个机房。



在架构设计上，也要考虑从主机房切换到灾备机房的方案。前面提到故障切换、“双活”和“多活”的思路同样可以运用到机房的灾备设计上。主机房与灾备机房之间的数据也需要同步，确保切换后，业务可以延续。



架构设计师需要充分了解各种硬件资源的配置、适应场景和处理能力（如果公司是自建机房，强烈建议对各种种类的硬件资源进行标准化。比如Linux服务器，有统一的品牌、型号和OS版本，有多个配置选项，从而提供同构的资源，简化管理，统一架构设计师的知识库，减轻架构设计师的认知负担，降低采购成本，降低机房的繁杂性。云服务商也是走这个策略的。）。



架构设计过程中，设计者需要和系统设计师、系统负责人充分了解系统设计、功能、特性和上下游系统关系。整个过程中，要保持沟通，小步推进，确保做出来的设计是得到一致认可的。



架构设计的输出包括架构设计图以及详细的硬件资源清单，资源清单包含网络、服务器、存储、中间件、数据库等的具体类型和配置。将来将按照这份清单来获取硬件资源。



后面会有一些非互联网架构的一些设计示例展开讲述。



设计评审



设计初稿最好得到资深架构设计师的审阅。



获取硬件资源



根据审批的架构设计及硬件资源清单，获取相应硬件资源，从而可以开始进行系统安装和部署。



03 一些样例



以下是一些具体的架构设计样例，供参考。



前面提到，生产环境必须要考虑灾备，因此几乎所有生产环境的架构设计图纸都是以下这样的“双肺”形式。



几乎所有在生产环境的资源都要在灾备环境配置一套，以便生产环境的硬件资源或机房出现故障时，可以快速切换到灾备环境。



这张图是一个典型的MVC模型架构。在图中，应用服务器和数据库服务器在生产环境和灾备环境均只有一套，因此一旦生产环境中的硬件资源出现不能短期恢复的故障时，只能通过切换到灾备环境来“续命”。由于切换到灾备环境需要一些时间，因此这张图其实RTO将是数个小时（具体多少小时将取决于每家公司机房针对各硬件资源切换的承诺时效），也就是最多可允许停机数小时的方案，适合业务重要性不太高的系统。



为了满足快速切换，在设计中考虑到了以下因素：



• 生产环境和灾备环境间应用服务器通过NAS（Network Attached Storage：网络附属存储，简单理解就是一种共享存储）保存文件，这样两套服务器间的文件是共享的，切换后也能访问到切换前的所有文件。



• 生产环境和灾备环境间应用服务器通过网关配置了主/备切换，一旦生产环境的服务器（主机）不响应，请求会自动切换到灾备环境的服务器（备机），无需人工干预。



• NAS在生产环境和灾备环境也备了两套，并进行了同步。一旦生产环境的NAS坏了，两台应用服务器可以挂到灾备NAS，并访问到已同步的文件。



• 这个例子的数据库采用的是Oracle。生产环境和灾备环境间数据库通过Oracle Data Guard进行数据同步，确保切换后系统可以获取同样的数据。



• 数据库建议存储在像NAS或SAN（存储区域网络Storage Area Network）的共享存储中（请自行补习NAS和SAN的区别，NAS比SAN便宜），保障性更高。



测试环境由于只需要备份，不需要考虑灾备，通常是“单肺”的形式：



如果业务重要性更高，从而对RTO的要求更高，则需要考虑在生产环境中实现多个服务器的“多活”、“双活”或故障切换。以下是一个示例：

在这个例子中，在一个环境里，应用服务器也有两套，它们通过网络负载均衡器实现了“双活”，用户请求会分发到这两台服务器上，在两台服务器均可用的情况下，请求处理量也比单机增加了一倍。万一其中一台服务器挂了，业务并不会中断，虽然处理能力会下降一半。



数据库服务器也在同一个环境中配置了两台，并通过VCS （Veritas Cluster Server，是VERITAS公司开发的一款高可用的多机热切换软件，可以通过应用在各服务器之间的智能化灵活切换，使多台服务器协同工作）实现故障切换，一旦主服务器出现了故障，可以自动切换到备用服务器，延续服务。



这里增加的在同一环境中的冗余设计，将大大降低更繁琐、耗时更长的灾备切换的几率，从而提升RTO。



如果系统是重度依赖数据库的，性能瓶颈会集中在数据库，可以考虑采用下图所示的数据库“多活”方案。



该方案在每个环境配置了3台数据库服务器，并通过Oracle RAC （Real Aapplication Clusters）实现了多点负载均衡，在3台服务器都可用的情况下，可以提供相对于单机近3倍的处理能力。



应用服务器有需要的话也可以从“双活”提升到“多活”，增加处理能力。



以上示例均为非互联网/云架构，在金融这样的传统企业比较多见。



所谓互联网/云架构，会充分利用分布式设计和异步处理，实现更强的伸缩性从而灵活应对波动巨大的流量，并能充分结合云计算所带来的即时按需租用、自动伸缩以及大量基础服务。我将在今后和大家具体介绍。但今天介绍的思路也能帮助大家理解更繁杂的互联网/云架构。



04 总结



我在《高级人才的价值在于管理复杂性的能力》提到过，一个优秀的架构师需要以下能力：





• Technical Excellence 技术牛 - 这个不用多说；



• Communication Mastery 沟通达人 - 架构设计绝对不是画张图那么简单，你需要和不同技术团队进行深入交流，才能做出切实可行的架构方案；



• Leadership Power 领导力 - 同理，只要需要协作，就需要领导力。你的图纸，别人不买账，就是废纸一张。



架构设计并非高不可攀的能力，软件工程师们除了低头写代码，如果能抬头掌握更多的系统架构知识，并诉诸行动，将能为客户、用户、业务部门提供更全面的服务。



分割线 卡通



关于作者

刘华（Kenneth）



• 敏捷、精益、DevOps专家

• 公众号“敏于思 捷于行”博主

• 精通极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps工具栈

• 曾在GDevOps、DevOpsDays Meetup、中国软件技术大会、ArchSummit等论坛发表主题演讲

• 著有《猎豹行动：硝烟中的敏捷转型之旅》一书