互联网服务架构设计漫谈（一）——设计考量点总览

1    概述

本文着重介绍在互联网应用服务器端的架构设计中需要关注的设计考量点，提供一个总览性认知。首先我们需要知道：不同类型的应用、不同用户规模和阶段的应用在架构设计的考量点都是有差异的，架构设计的挑战以及侧重点也都存在差异，具体问题需要具体对待。本文会介绍各种可能的考量点，提供每种考量点各类可能的解决思路，给读者提供一个宏观的视野，后续会陆续单独写文章对本文中提及的思路展开详解。

业界有很多不同维度架构设计的理论和术语，例如CAP理论、高可用性、服务治理等概念。本文从我自己多年的实践经验的角度，提供更加贴合实战的理解和描述。

我目前将架构设计考量点总结为9个重要方面，包括性能、稳定性、可伸缩性、可扩展性、数据一致性、可运维性、安全性、数据实时性、智能化。

 

2    性能

性能是互联网应用中最重要的体验之一，响应慢的应用会让用户流失，Google就曾通过数据和严谨的实验证明这一点。

在实践中，我们会通过请求平均响应时间、请求响应时间分位值（80分位、90分位、95分位等）、页面加载时间等指标来度量性能。在用户层面，3秒以上加载时间就超出接受范围，几百毫秒内体验较佳。对已有系统或者初步研发完毕新系统的性能问题，我们需要通过压测、性能诊断工具或代码等方式来了解性能现状以及定位性能差的环节。不同性能瓶颈原因的解决方案不同，同一个问题因为当前的硬件资源能力、解决问题所能付出的时间、人力成本等不同都可以选择不同的折中方案，选择适合自己当前阶段的解决方案很重要。

下面简单介绍一些解决性能问题的思路：

1） 解决代码中性能bug

根据代码等细节诊断定位的原因，修复不合理锁等待、日志输出过多、不合适的大资源申请、代码不合适循环调用、网卡&硬盘等硬件故障等明确问题。

2） 缓存

缓存是一个万金油方案，在系统各个层次都可以加上不同层级缓存，在不同层次可以设计出不同复杂度缓存方案，在达到一定缓存命中率的情况下，就能有效减少资源请求、减少计算等问题，提高单个命中请求的性能，也降低整体资源负载。例如在请求入口层，可以用redis、memcache等构建一个请求缓存，对于同样的查询请求， 优先查询cache，cache命中则直接返回结果，无需再进行数据库等存储请求以及业务计算。缓存方案需要关注缓存更新机制，避免出现用户感知或影响业务数据的脏缓存问题。

3） 数据库存储优化

对于大部分业务系统而言，mysql等标准数据库就能满足其存储需求。数据库设计以及性能优化需要重点掌握。有几种思路：

a） 针对业务查询特点，优化查询索引，提高查询性能

b） 数据量较大时，对数据库进行横向或纵向拆分，进行合适分库分表设计

c） 针对目前的库表设计，做sql查询语句优化

d） 针对业务事务性、数据丢失级别等特征，选择合适存储引擎、日志级别等配置、复制配置等。

e） 硬件层次：使用更好的硬件，如使用SSD硬盘。

4） 并行化

请求中有多个处理流程，例如业务处理逻辑独立、可以同时请求的多个资源、同一个数据源可以拆分并行获取等情况，串行做时间久，可以拆分为并行处理。

5） 异步化

部分业务逻辑可以异步处理的，可以通过异步队列、消息系统解耦，异步处理。如果用户需要关注处理进度和结果的，可以通过进度条、处理状态等产品端形态让客户感知和建立预期。

6） 内存化： 大量资源加载或部分预加载到内存，直接内存式访问。例如搜索索引查询等场景

7） 大数据在线查询场景，可以用列式存储等更切合查询场景特殊存储。

8） 外网大量静态资源：可以通过cdn方式加速客户端资源传输速度

9） 外网复杂网络情况，可以部署异地多机房、机房多运营商入口（dns解析客户相同运营上入口）等；更大规模、更大商业价值的应用，有可能的可以在多机房之间通过私有光纤等传输速度以及稳定性更加的私有网络。

10）        自身资源有限的情况，使用目前各大云计算厂商的各类强大网络以及计算能力，也是小成本获取复杂和重量级解决方案的好选择。

3    稳定性

服务稳定性是一个很大的概念，广义上性能、安全等都可以将其算为稳定性，由于本文会讲解各种其他方面，这里稳定性特征狭义的稳定性：即正常逻辑情况下正常服务程序，在某些问题（非外部攻击）触发或者部分使用场景下，无法响应或处理出错。稳定性可以通过SLA的不同级别来度量，例如几个9的稳定性，详细可自行网上搜索，

导致稳定性问题原因多种多样，有硬件故障、网络故障、人为操作失误、服务隐藏bug等，且无法一劳永逸。因此，稳定性既要加强技术上的保障，也要增强流程规范性、强化人员责任意识，警钟长鸣。技术上的措施可能有：完善错误日志、完善监控报警以及稳定性监测统计、完善代码分支中异常逻辑处理、设计上排查以及规避单点故障、服务自动降级处理、自动化故障处理、自动化运维、自动化测试；人的方面可能措施有：上线流程规范（审核、小流量上线、线上回归）、报警快速响应处理（值班机制）、权限控制（不同熟练程度不同控制权限）、人为操作尽量自动化（利用界面平台进行线上操作）、定期整体线上排查以及监测稳定性、线上问题系统Case Study。

4    可伸缩性

可伸缩性是指当流量增长导致当前服务器资源比较紧张时，当前服务架构是否可以通过加机器的方式扩充来处理更多访问。可伸缩性是当前很大大型分布式性系统、通用系统需具备的特性，例如hadoop、spark等。在程序架构设计时，我们要对我们应用增长要有一定预判，在一定流量增长倍数内（例如5到10倍），我们应能通过架构留下扩充空间来支持。

可伸缩性在计算层可以有多台不同计算节点（如web server）做负载均衡；在业务逻辑处理层可以按照用户id等进行分区处理；在cache层或存储层可以基于已有非集群的存储程序加上分区、分表等设计，来扩充，也可以直接使用具备分布式集群能力的存储，也可以借助通用云计算服务。需要关注的点有当服务伸缩时，上游程序如何感知到伸缩变化；当存储伸缩时，数据如何不影响业务情况下，完成数据重新分区。小型程序可以手工完成分区，大型程序则需要通过zookeeper等工具进行通用配置管理、任务系统自动化做数据均衡和迁移。

5    可扩展性

可扩展性是指业务逻辑变动或者增加时，代码层次可以比较容易变动或更改，改动成本小。如果碰到一点点逻辑的变动或增加要改动N多地方代码或新增新的逻辑容易导致已有业务逻辑bug等情况下，那该服务代码可扩展性可能存在问题。可扩展性体现设计人员抽象、组织能力，如何使系统整体框架清晰、子系统子模块之间边界清晰和解耦、子模块内部逻辑内聚、子系统之间接口清晰且灵活可扩展。常见措施有： 1）纵向划分，将系统功能分层，不同层次承担不同功能，例如MVC的视图模型层分离，服务的负载均衡层、业务计算层、通用服务层、存储层等划分。 2）横向划分：按照业务功能拆分为平行的不同子业务模块、子服务。3）合适利用工厂模式、适配器模式、命令模式等设计模式来进行功能代码的组织，同时关注通用代码的抽象复用。4）设计灵活可扩展的接口或协议。

6    数据一致性

数据一致性要求是指业务系统中多个环节数据或业务场景是否要求数据具备一致性。一致性的级别有强一致性、最终一致性、弱一致性等多个级别，具体参考。例如转账等金钱相关的重要系统，需要给用户提供强一致性的体验。对于复杂业务系统，保障各个环节的数据一致性的成本是非常大，一些常见的数据一致性保障思路有：核心数据收敛到同一个数据库，利用数据库自身强大事务保障机制来保障；将业务流程拆分成多个小的事务环节，后续事务环节异步进行（例如转账分为转出以及记录转出交易记录、读取交易记录转入并记录转入交易记录、定期核验转出和转出交易记录核账清理）；将同一用户请求收敛到同一个计算节点，利用统一计算节点的缓存或一段时间内强制读取同一主副本来保障；利用短时缓存屏蔽数据库主从不一致等；使用针对业务特点开发的做了一致性特殊保障存储或者消息系统。

7    可运维性

可运维性是指系统是否能高效率高可靠地进行上线部署、升级、迁移、故障处理等运维操作，高可运维性的系统即是可以提高运维效率，更可以减少人为引入的操作故障。运维性的级别可区分为：手工操作、脚本化启停、批量脚本化运维、自动化部署系统、云计算托管&自动化故障处理&伸缩，这些不同级别对应用不同层次的运维方案。

8    安全性

当前互联网系统覆盖行业越来越多，涉及商业价值以及利益也非常巨大。安全性是每个具备商业价值的互联网服务必须考虑的问题，在相对级别以上公司，都会配备专门的安全部门以及专门安全技术专家来统一监管和防控安全隐患。这里介绍一些业务系统研发设计过程中一些安全防范思路：非公开信息访问做登录认证保护、提升用户密码安全等级、密码等信息加密或不可逆加密存储、内网系统收敛为内网访问（不提供公网域名以及ip）、非外部访问的子系统收敛到内网访问、内网子系统之间访问接口要求有验证码、内网子系统之间要求参数加密校验协议、外网客户端到服务器之间需要参数加密校验&端动态统一的账户和token认证子服务、规避sql注入问题、业务系统中进行权限分级、数据访问白名单或黑名单保护、重要系统通过https访问或设计公私秘钥认证或硬件秘钥认证；进一步可利用云计算技术（虚拟化隔离）、专业厂商提供的防DDos攻击保护等通用安全技术提供安全保障。

9    数据实时性

对于一些离线或异步化处理的系统，数据实时性也会是重要设计考虑目标。例如搜索广告系统中点击计费、预算控制、广告物料更新等技术，实时性的提升会直接带来更多商业收入。实时性需要协同考虑数据的一致性保障，这里的思路可能有：做流程优化（减少核心数据的处理环节）、利用可靠性消息和数据传输系统（甚至单独开发）等。

10       智能化

智能化是指是否充分利用业务产生大量业务以及用户数据，构建智能化应用，来提升服务价值和体验。具体而言，架构设计中需要考虑记录各类数据、搭建数据体系以及持续积累各类业务过程数据、在业务系统中充分利用大数据（数据驱动业务、机器学习建模以及应用等）来决策以及改善产品体验。

11       结语

本文从宏观视野介绍了互联网服务端架构设计的9个考量点：性能、稳定性、可伸缩性、可扩展性、数据一致性、可运维性、安全性、数据实时性、智能化，并做了简单展开以及提供一些可能设计思路。需要强调下，不同业务不同阶段的应用的考量点侧重点有差异，因此，智慧的架构师要能设定符合业务阶段的设计目标以及选择适合自己的设计方案。