架构设计核心理念

一、架构设计核心原则

架构设计的主要目的是为了解决软件系统复杂度带来的问题。

架构设计三原则：合适原则、简单原则、演化原则

• 合适原则宣言：“合适优于业界领先”。
• 简单原则宣言：“简单优于复杂”。
• 演化原则宣言：“演化优于一步到位”。

二、架构设计的复杂性

2.1、高性能

  性能是软件的一个重要质量属性。衡量软件性能包括了响应时间、TPS、服务器资源利用率等客观指标，高性能的目的是追求良好的用户体验；满足业务增长的需要。

  软件系统中高性能带来的复杂度主要体现在两方面，一方面是单台计算机内部为了高性能带来的复杂度；另一方面是多台计算机集群为了高性能带来的复杂度。

  垂直维度主要是针对单台计算机，通过升级软、硬件能力实现性能提升；水平维度则主要针对集群系统，利用合理的任务分配与任务分解实现性能的提升。

  垂直维度方案比较适合业务阶段早期和成本可接受的阶段，该方案是提升性能最简单直接的方式，但是受成本与硬件能力天花板的限制。垂直维度可包括以下措施：

• 增大内存减少I/O操作
• 更换为固态硬盘（SSD）提升I/O访问速度
• 使用RAID增加I/O吞吐能力
• 置换服务器获得更多的处理器或分配更多的虚拟核
• 升级网络接口或增加网络接口

  水平维度方案所带来的好处要在业务发展的后期才能体现出来。起初，该方案会花费更多的硬件成本，另外一方面对技术团队也提出了更高的要求；但是，没有垂直方案的天花板问题。一旦达到一定的业务阶段，水平维度是技术发展的必由之路。因此，作为技术部门，需要提前布局 ，未雨绸缪，不要被业务抛的太远。水平维度可包括以下措施：

• 功能分解：基于功能将系统分解为更小的子系统
• 多实例副本：同一组件重复部署到多台不同的服务器
• 数据分割：在每台机器上都只部署一部分数据

2.2、高可用

  需求驱动驱动；而高可用与高性能，是架构设计中两个非常重要的决策因素。因此，面对不同业务系统的不同需求，对高可用与高性能也会有不同的决策结论，其实现的复杂度也各不相同。为此，高可用性与高性能的复杂度讨论需要结合业务需求。

  定义可用性，可以先定义什么是不可用。软件其中的任何一个环节出现了故障，都可能会导致最终的不可访问。我们可以利用百分比来对可用性进行度量：

• 不可用时间=完成故障修复的时间点 - 故障发现的时间点
• 年度可用时间=年度总时间 - 不可用时间
• 年度可用性=(年度可用时间/年度总时间) x 100%

可见，高可用性就是技术实力的象征，高可用性就是竞争力。

为什么会出现不可用？

• 硬件故障。
• 软件BUG或更新升级发布。
• 不可抗拒力。如地震、水灾、战争等。

  高可用的主要技术手段是服务与数据的冗余备份与失效转移。同一服务组件部署在多台服务器上；数据存储在多台服务器上互相备份。通过上述技术手段，当任何一台服务器宕机或出现各种不可预期的问题时，就将相应的服务切换到其他可用的服务器上，不影响系统的整体可用性，也不会导致数据丢失。

  从架构角度看可用性：当前系统多采用经典的分层模型，从上到下为：应用层、服务层与数据层。应用层主要实现业务逻辑处理；服务层提供可复用的服务；数据层负责数据读写；在部署架构上常采用应用和数据分离部署，应用会部署到不同服务器上，这些服务器被称为应用层的服务器；这些可复用的服务也会各自部署在不同服务器上，称为服务层的服务器；而各类数据库系统、文件柜等数据则部署在数据层的服务器。

  硬件故障方面引起不可用的技术解决措施：

• 应用服务器。可通过负载均衡设备将多个应用服务器构建为集群对外提供服务，当均衡设备通过心跳检测手段检测到应用服务器不可用时，则将其从集群中移除，并将请求切换到其他可用的应用服务上。
• 服务层服务器。这些服务器被应用层通过分布式服务框架访问，分布式服务框架可在应用层客户端程序中实现软件负载均衡，并通过服务注册中心提供服务的服务器进行心跳检测，当发现有服务器不可用时，立即通知客户端程序修改服务列表，同时移除响应的服务器。
• 数据服务器。需要在数据写入时进行数据同步复制，将数据写入多台服务器上，实现数据冗余备份；当数据服务器宕机时，应用程序将访问切换到有备份数据的服务器上。

  软件方面引起不可用的技术解决措施：

• 通过软件开发过程进行质量保证。
• 通过预发布验证、严格测试、灰度发布等手段，尽量减少上线服务的故障。

2.3、可扩展

  业务需求、运行环境方面的变化都会导致软件系统发生变化，而这种软件系统对上述变化的适应能力就是可扩展性。可扩展性可以理解为是一种从功能需求方面考虑的软件属性，属性就会存在好坏之分。
  伴随业务的发展、创新，运行环境的变化，对技术也就提出了更多、更高的要求。能够快速响应上述变化，并最大程度降低对现有系统的影响，是设计可扩展性好的架构的主要目的。
  按照可扩展性的定义，一个具备良好可扩展性的架构设计应当符合开闭原则：对扩展开放，对修改关闭。衡量一个软件系统具备良好可扩展性主要表现但不限于：

• 软件自身内部方面。在软件系统实现新增的业务功能时，对现有系统功能影响较少，即不需要对现有功能作任何改动或者很少改动。
• 软件外部方面。软件系统本身与其他存在协同关系的外部系统之间存在松耦合关系，软件系统的变化对其他软件系统无影响，其他软件系统和功能不需要进行改动。反之，则是一个可扩展性不好的软件系统。

  伴随业务的发展、创新，运行环境的变化，对技术也就提出了更多、更高的要求。能够快速响应上述变化，并最大程度降低对现有系统的影响，是设计可扩展性好的架构的主要目的。面向对象思想、设计模式都是为了解决可扩展性的而出现的方法与技术。

  伴随业务的发展、创新，运行环境的变化，对技术也就提出了更多、更高的要求。能够快速响应上述变化，并最大程度降低对现有系统的影响，是设计可扩展性好的架构的主要目的。设计具备良好可扩展性的系统，有两个思考角度：

• 从业务维度。对业务深入理解，对可预计的业务变化进行预测。
  在业务维度。对业务深入理解，对业务的发展方向进行预判，也就是不能完全不考虑可扩展性；但是，变化无处不在，在业务看得远一点的同时，需要注意:警惕过度设计；不能每个设计点都考虑可扩展性；所有的预测都存在不正确的可能性。

• 从技术维度。利用扩展性好的技术，实现对变化的封装。
  在技术维度。预测变化是一回事，采取什么方案来应对变化，又是另外一个复杂的事情。即使预测很准确，如果方案不合适，则系统扩展一样很麻烦。第一种应对变化的常见方案是将“变化”封装在一个“变化层”，将不变的部分封装在一个独立的“稳定层”。第二种常见的应对变化的方案是提炼出一个“抽象层”和一个“实现层”。

  在实际软件系统架构设计中，常通过以下技术手段实现良好的可扩展性:

• 使用分布式服务(框架)构建可复用的业务平台。
  利用分布式服务框架(如Dubbo)可以将业务逻辑实现和可复用组件服务分离开，通过接口降低子系统或模块间的耦合性。新增功能时，可以通过调用可复用的组件实现自身的业务逻辑，而对现有系统没有任何影响。可复用组件升级变更的时候，可以提供多版本服务对应用实现透明升级，对现有应用不会造成影响。
• 使用分布式消息队列降低业务模块间的耦合性。
  基于生产者-消费者编程模式，利用分布式消息队列(如RabbitMQ)将用户请求、业务请求作为消息发布者将事件构造成消息发布到消息队列，消息的订阅者作为消费者从消息队列中获取消息进行处理。通过这种方式将消息生产和消息处理分离开来，可以透明地增加新的消息生产者任务或者新的消息消费者任务。

2.4、低成本

  低成本是架构设计中需要考虑一个约束条件，但不会是首要目标。低成本本质上是与高性能和高可用冲突的，当无法设计出满足成本要求的方案，就只能协调并调整成本目标。

  一般通过“创新”达到低成本的目标：

• 引入新技术。主要复杂度在于需要去熟悉新技术，并且将新技术与已有技术结合；
• 开创一个全新技术领域。主要复杂度在于需要去创造全新的理念和技术，并且与旧技术相比，需要有质的飞跃，复杂度更高；

2.5、安全

  安全是一个庞大而又复杂的技术领域，一旦出问题，对业务和企业形象影响非常大。从技术的角度来讲包括以下几点：

• 功能安全-“防小偷”，减少系统潜在的缺陷，阻止黑客破坏行为；

• 架构安全—“防强盗”，保护系统不受恶意访问和攻击，保护系统的重要数据不被窃取。由于是蓄意破坏系统，因此对影响也大得多。架构设计时需要特别关注架构安全。

• 功能安全。是一个逐步完善的过程，而且往往都是在问题出现后才能有针对性的提出解决方案，与编码实现有关。

• 架构安全。传统企业主要通过防火墙实现不同区域的访问控制，功能强大、性能一般，但是成本更高。互联网企业更多地是依靠运营商或者云服务商强大的带宽和流量清洗的能力，较少自己来设计和实现。

2.6、规模

  规模带来复杂度的主要原因就是“量变引起质变”，当数量超过一定的阈值后，复杂度会发生质的变化。随着业务的发展，规模带来的常见复杂度有：

• 业务功能越来越多，调用逻辑越来越复杂；
• 数据容量、类型、关联关系越来越多。

  规模问题需要与高性能、高可用、高扩展、高伸缩性统一考虑。常采用“分而治之，各个击破”的方法策略。