大型互联网系统技术架构设计的4个基本要素

作为一名大厂SRE，对什么是好产品（技术架构角度）有深刻的感悟。一个好产品的技术架构不仅在优秀的代码本身，更体现在后期的易运维性、可扩展性、高可用性上。随着用户体量、产品功能、IaaS、PaaS的变化甚至员工的离职，随时需要动态调整架构改变策略来应对各种问题，而这些场景都是对技术架构是否优秀、是否有张力的一次次考验。

如果是新产品，在早期SRE就要参与进来了，同步参与制定接入架构、部署架构、高可用架构和运维方案。因为做出来的产品最终都要交付上线、放到生产环境给用户服务的，SRE更加了解线上环境，研发阶段简易的demo放到线上会遇到各种问题；再就是开发过程如果缺少运维意识，上线后再做策略调整可能会遇到各种麻烦；另外运维人员会根据模块属于不同的IO、cpu、内存消耗型等特点提出更加合理的服务器规格，SRE提前参与对系统的云端成本、性能和高可用都会有很大帮助。

根据经验，总结了大型高并发系统的4个基本要素：

1. 功能模块化(微服务)、高内聚低耦合

大型互联网应用面对全国乃至世界范围内使用，要应对开发分工、快速迭代、弹性扩缩等场景，无时无刻都在开着汽车换轮胎，而且要保证驾驶平稳不能宕机翻车，保证优秀的用户体验、友好的迭代升级和业务扩展。

综上，要解决这些问题，只有用微服务的思想进行架构设计，对模块进行结构化分层拆分，一个没有模块拆分的系统是不可能完成这项任务的，想想几百号人围绕着一套代码转是个什么样子。

一个优秀的大型互联网应用会在设计之初就进行模块化，每个模块各司其职，模块间通过REST/RPC/消息队列进行通信，通过注册中心/配置中心进行服务的治理，各模块根据工作量和难度分给不同项目组负责，最后单个模块形成高内聚、模块之间形成低耦合的模型，该是谁的事儿就找谁，模块怎么划分更加科学，要做技术研讨，研讨中一定要用发展的眼光看问题，从当前开发的科学性和后期上线可运维性两个维度来做考虑。

2. 服务独立易部署、弹性可扩展

要应对线上变化的环境、用户量的自然及突发性增长、开发者的人员变动，每个功能模块在做到功能独立高内聚的同时，要做到运维的可交付、资源的可弹性扩展。

运维的可交付体现在模块的易部署（越简单越好），部署过程不依赖修改源代码，所需的配置文件、代码可以做到统一下发,如果能够直接容器是最好的，所有问题迎刃而解。

资源的弹性扩展是为了应对用户量的自然及突发性增长，比如说要做一个活动，访问量会突发翻倍，这时模块要能做到易扩展，可以弹性的通过简单的扩容服务器或Pod来增加系统吞吐量，不至于造成系统瓶颈，每个模块能做到弹性，整个应用才会变成一个弹性可伸缩的强大产品。

3. 具备完善的逃生能力、架构皮实

系统的用户体量增长到一定程度，是不允许出问题的。比如说微信，基本变成人们生活的日常，每个人都严重依赖它，慢慢更像是一个民生工程了，一旦出问题就会对很多人的生活带来严重的影响，进而带来大量用户的投诉和不满，小米万物互联的系统米家和小爱同学现在也在这个方向上，系统一旦故障大量的用户不能控制智能设备，不一会儿就能冲上热搜，所以对大型互联网系统就提出了更高的要求。

但是系统本身又是不可能不出故障的，大型互联系统本身就很复杂，再加上运行环境、依赖的资源的复杂，出问题是再正常不过的，但如何保证局部出问题不影响整体，个别出问题不影响核心，甚至能够在出现故障后自动检测自动愈合，这些对应的就需要通过技术方案来解决了。因为故障不可避免，所以一个优秀的系统必须具备完善的逃生能力，故障时快速逃生，才能从容的面对各种故障带来的影响，缺失逃生能力的技术架构一定不是一个好架构，大型互联网系统架构一定是越皮实越优秀。

逃生能力技术架构的设计是一个很大的主题，牵涉的内容很多，这部分后面单独作为主题讲解。

4. 打点、日志健全，可分析、可监控

打点和日志反应的是系统故障的发现能力以及排查能力，一般是通过告警发现故障，通过日志、监控分析故障具体原因。

日志的健全性很重要，通过对日志的监控可以及时的发现问题、分析问题、分析模块的性能、故障点等等，其包含但不限于操作系统日志、业务日志（访问、超时、错误）、后端资源依赖日志等，分析的结果同时正向反馈到下一步的产品迭代研发中。

对于监控，也分为了基础监控、应用软件监控、业务监控、依赖监控四个层面，简单介绍一下，基础监控指服务器各种基本指标包含cpu、负载、io、内存、网卡流量等监控，应用软件指nginx、tomcat等应用软件本身性能的监控，业务监控是指访问后或对于任务处理情况的日志监控，比如说nginx的访问日志，依赖监控是指其依赖模块或资源的监控，比如说mysql、redis等。

花有花期，人有时运只要变好，慢点妨