认识达内从这里开始

软件架构是我们在学习软件编程开发技术的时候会接触到的一个概念，而今天我们就通过案例分析来了解一下，程序员需要掌握哪些软件架构设计的相关知识。下面就开始今天的主要内容吧。

1、确定业务重要性

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

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

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

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

2、收集非功能性需求

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

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

3、架构设计

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

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

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

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

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

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请在707945861群中学习了解。