2.3.5 架构的稳定性和效率

与传统的互联网架构相比，移动平台架构在并发量、安全性等方面存在更大的挑战，移动架构的稳定性和效率等问题变得更为重要。本节主要对影响移动架构性能的因素，尤其是稳定性和效率问题进行探讨。

移动互联网时代，业务需求的变化比PC时代要快很多；移动用户遍布全球，无固定地点；企业整体移动应用绝大多数还要与后台信息系统实现有效集成，所以移动互联网不仅是传统互联网的延伸，更是一种打破与重塑。在传统PC时代，B/S架构常常被理解为C/S架构的一种变体，只不过在客户端，我们运行在Browser这样一个容器环境中，通过稳定的带宽网络接入与HTML这样简单透明的协议与服务段进行通信。这里工程师的主要工作是集中解决兼容性的问题，所有的逻辑运算与核心问题，而扩展性、伸缩性、稳定性、性能等问题都集中在后端解决。在移动时代，移动设备计算能力的发展越来越迅猛，在终端应用侧可以做到更多Browser无法实现的事情，我们真正进入了富客户端时代，之前谈论的很多架构问题，如扩展性、隔离性、稳定性、性能等很多问题就不仅是服务端问题，客户端也需要从架构的维度来进行仔细设计。同时，移动端极其注重用户的真实体验，应用的启动、页面的渲染要快捷，页面之间的切换、滑动要流畅；页面布局要清晰，应用的交互要遵循用户习惯，简单直观；应用的功能要稳定可用，这对基础架构提出了更高的要求。另外，挑战来自不稳定的移动网络环境，传统PC时代，我们访问网站的接入条件是相对恒定的，所以在开发时很少考虑网络对于用户体验的影响。移动App则不然，移动用户不分地点地访问服务，尤其在地铁、公交车这样的环境下，移动基站的频繁切换进一步增加了网络的不稳定。如果端到云的连接不稳定、延时高，那么用户体验无从谈起。所以，移动端架构的主要演进方向是隔离性、动态性和极致的网络体验。

传统的移动App开发和集成方式并不适合企业级开发，一个具备很好隔离性的模块化架构是大规模并行开发的基础。很多企业在移动化初期的架构是ALL IN ONE模式的，就像一个单机系统，所有的东西都部署在一台机器上；随着业务的发展，企业会一个一个地往后堆系统，就像2.3.2节讲到的“烟囱式”架构，这种架构设计在当时能够满足业务需求，快速抢占市场，但随着平台化的发展及业务越来越复杂和多样性，这种架构会带来很多问题。首先是强耦合，不同的功能模块交叉在一起，牵一发而动全身；然后是稳定性不足，当流量高速增长时，很容易宕机；另外，代码冗余会影响开发和维护效率，也不利于扩展。这类问题通过对模块和服务的隔离和解耦进行解决。平台将耦合在一起的服务进行拆分，服务与服务之间通过接口来调用和访问，服务要保护自己的相关资源如数据库等。在硬件拆分上，企业把负载压力分摊到多台机器上，形成分布式系统。软件层面如逻辑计算部分可进行垂直拆分。垂直拆分是指将站点业务逻辑垂直拆分成首页、发布页等不同业务页面；将数据库垂直拆分，将大数据量拆分成小数据量；将代码垂直拆分成不同的模块，这种垂直拆分的方法可以有效缓解读写延时、站点耦合和数据加载过慢的问题。

互联网一切以效率为先，从架构上将希望能够在富客户端时代同样能保留Web的轻盈和灵活，动态性是很重要的前提，架构需要具备一定程度的运行期调整和动态部署能力。由于移动应用的多平台性，一种应用功能需要在Android和iOS上重复实现，企业既要面对移动端APK包大小和方法数的限制，同时又要支持多样的功能升级、多平台的持续交付、覆盖度、容错、热修复等庞杂的事情。所以在设备和操作系统的限制下实现动态伸缩，企业需要一个轻量灵活的解决方案，能够基于高度重用的基础模块进行低成本的并行开发和快速发布。

企业可以通过改善网络通道，突破运营商基础网络的局限性，不管用户在何种网络环境中，力争为用户创造顺畅的应用体验。使用更高效的通信传输技术，提高连接复用，减少round-trips次数，通过更高效的压缩技术和同步技术减少网络流量；在本地建立HTTP DNS服务并缓存，减少客户端DNS检索的时间损耗，同时优化传输层安全性协议，在不降低体验的基础上提升数据的安全性；将网络能力整体封装成标准的SDK，一方面确保App群能够一起享受整个优化的收益，另一方面确保H5页面能够使用Native通道的能力。

针对企业业务要求的不同，架构稳定性的指标也要进行相应的调整，如若是销售业务，订单的可靠性是架构稳定性评判的重要标准。保证架构的稳定性可以从日常运行、事前预警、事故处理和事后总结四个环节进行。

● 日常运行环节有几个原则，一是大系统小做，就是之前提到的服务解耦合模块独立；二是依赖稳定性原则，平台提供的服务一定要是稳定可靠的，将易变的服务与不变的服务拆开，例如，某些业务管理的功能经常变化，但读取的信息是不变的；三是重视用户体验，在设计的时候需要考虑异常情况下用户的体验和用户如何引导。日常运行环节的另一个工作是例行的稳定性检查，如对场景、服务进行静态梳理，还有对指标进行监控，如在线压测的监控指标。

● 在事前预警环节，企业希望异常事故能够更早地暴露出来，触发报警，这样就可以有充分的时间进行应对。事前预警环节最有效的手段就是进行监控，平台可以提供分层的监控数据，有系统级的监控，如性能指标的监控，还有业务监控，如健康度的分析。

● 事故处理环节的第一原则就是及时止损。新版本发行是导致稳定性变化的重要因素，解决该问题最快速、最有效的方法就是回滚。还有一种可能是流量异常。对于异常流量，要进行限流，限流的策略有：执行防御和隔离、防刷；等待限时；流量优先级控制，避免无用任务占用CPU；单机服务熔断机制；等等。当系统出现问题时，允许进行服务降级，确保机器在稳定运行的情况下尽可能地提供服务。

● 事故发生后要对事故做深刻的总结。要找到根源，核算损失，也要对系统出现问题的过程、处理的过程和中间的流程进行总结优化。

互联网以效率为先，而稳定性需求恰好与效率相矛盾，企业需要根据当前的业务发展进行权衡。对小团队和初创型团队而言，效率十分重要，对架构的稳定性需求就可以适当放松；对大型企业而言，很多服务的实现都是跨部门合作的，架构的稳定性十分重要。总而言之，性能和稳定都是功能的一部分，企业需要根据当前的业务发展对二者进行权衡。