背景
我现在负责的项目是一个合同型项目，也就是甲乙方关系。目前我们系统累计用户数约2500万+，日活跃200万+。而今年客户的KPI指标是用户总数翻一翻。而刚好这几天我需要给客户汇报一份关于“如何支撑数千万级别用户”的系统报告。借此机会，也顺带多写一份分享心得。
前序
从项目性质可以看出，我们公司就是一个IT服务企业，既然是服务，那么客户的满意就是我们前进的动力，注意是客户而不是用户。客户提出这个汇报要求，无非要的就是我们能否协助他们完成KPI的信心。再进一步说，就是我们开发的系统能否很好地支撑他们达到业务和用户的KPI目标。首先我会想到的一点是，今年将会是一个怎样的数千万用户级别系统，也就是说这个数千万用户系统的背后需要支撑什么样的业务目标。例如数千万用户的秒杀和数千万用户的查询还是有天大的区别。按照我对该行业客户的了解，我是无法从中得知太多有利用价值的商业信息。所以他们实际要的就是一个“能快速响应、随机应变且能支撑数千万用户的系统”。能快速响应意味着我们要随时能跟上他们紧急的需求新增或紧急的需求变更；随机应变也就意味着他们想做什么就做什么且不能拒绝；数千万用户就是一个代表并发的量词，他不会告诉你这数千万用户什么时候一个个来或什么时候会一起来。客户对系统的要求也不多，也就“稳定、灵活、可扩展和敏捷开发”四个要求。下面就来说说我将会通过什么样的手段来满足客户的欲望。
主题
从宏观角度看，一个系统并非只是一个硬件+软件的集合那么简单，它还涉及到其它方方面面的因素，这些因素间相互紧密关联，比如公关做不好或者业务方向偏轨，系统再好，也无补于事。从微观角度看，一个系统并非只是需求、开发、测试的事情，我们还要考虑运维、实施等项目阶段成员的感受。一个项目的最大难度可能不是开发，或许可能是运维。一个项目的复杂度会随着时间的迁移或者骨干人员的变动而指数增加。从这些方面去考虑，这个系统必须保持足够的“简单”，才能降低项目的各种成本。当然，越简单越复杂，最终依赖的还是一个“简单”的团队。
简单的框架
从上图得知，该系统是一个面向服务体系结构（SOA）系统，也是“简单”的首先。该系统主张的是把所有服务组件化，最大的组件粒度是平台，例如运营平台、外部服务支撑平台、内部服务支撑平台等。而最小的组件粒度是服务。组件化也是系统灵活性和可扩展性的必要因素。平台垂直分为入口层和业务层，下面分别介绍一下。
入口层
入口层的主要职责就是充当业务系统门卫，检查业务请求的合法性，各检查组件之间松耦合，没有任何关联，随时能删能减，不会影响整个系统的稳定性。
业务层
顾名思义，业务层的主要职责负责对业务的逻辑处理，并响应用户业务请求。该业务层主要包含参数验证、逻辑处理、响应请求三大步骤。一个业务实体代表一种服务，各业务实体之间同样是松耦合，没有任何关联，缺少任何一种业务都不会导致系统的崩溃。
辅助组件工具包
这个工具包包含各种通用辅助组件，主要职责是辅助入口层和逻辑层各组件的执行，例如数据库操作组件、Redis操作组件等。
该系统的主要特点有:
1、控制业务粒度复杂度
没有不能简单的功能，只有乳臭未干的设计者。一个业务也相当于一个组件。一个过于复杂的组件无论从运维还是性能来说都是噩梦的开始。如果每一个组件都有它的“自管”能力，后续的运维工作就会大大的降低。
2、控制线程栈的大小
一个业务线程栈过大也就意味着线程执行时间不会太短，对于一个互联网应用，每一毫秒都是系统体验的关键所在。
3、控制系统透明度
所谓的透明度也就是线程栈的透明度，就是每个程序员都必须非常清晰的理解自己的线程栈将会如何运行，在什么地方会存在异常风险，如何处理等操作手段。也因为这样，整个系统没有使用任何其它的“业务逻辑开源框架”，大大地降低了开发人员的学习成本和压力，也大大地提高了系统的可控性。可以让程序员接触更多基础的东西。包括数据库的操作也是需要开发人员自己亲手去写业务的SQL语句，并保证SQL语句的性能消耗。当然，这也需要开发人员对数据库有一定的了解程度。
4、控制业务验证
对任何业务的请求都必须保持不可信任的态度，这也是业务实例的第一步就是做请求参数验证的必要性。服务是对外的，谁也不敢确保没有恶意的攻击，这个一个系统必须考虑的边界因素。否则系统毫无安全性可言。
简单的部署
部署同样遵守组件化、控制业务复杂粒度等原则。确保每个垂直的部署都是一个独立的业务集群，每个业务集群必须控制好业务的复杂度，好比如一个细胞成长到一定程度会自动分裂出两个细胞，否则胀爆是唯一的后果。从以上架构图中左边的两个箭头和系统特性得知，该系统可横向平台分解部署或同一平台中业务分解部署，大概的部署效果如下图所示：
如果资源和业务允许，各垂直集群硬件的独立性也是必要的，尽可能确保各部署集群之间的松耦合。对于实施人员来说，每个集群业务的部署，只需要从项目中提出属于该集群的组件增量部署即可。
简单的监控
监控程序同样是系统的重要组成部分，也意味着监控程序必须遵守以上系统原则去实现，并监控程序也是需要维护的。
总结
不难看出，整个系统都是体现组件化原则。每个层次的结构都可以通过水平横向组件化扩展来增加系统的支撑能力，这就是系统原则一致性的表现。随着时间的推移，业务复杂度不会因此而增加，只会横向地扩展更多的服务支撑。从系统架构特性也可以看出，对硬件资源的消耗也是非常的低，毕竟线程栈的大小也放在哪儿了，这一点也得到了客户的认可。此架构已经在线上支撑着每天200多万用户的使用，整一年下来故障率为0。
这个系统的学习成本也是非常低的，因为是都基础知识。虽然简单，但对人员的综合能力是有一定的要求。例如开发人员需要对整条访问线程的各个部分都要有所了解，例如网络、中间件、语言、缓存、数据库等知识，否则马不停蹄的救火和调优是未来可预知的事情。因为一个习惯了简单开发的程序员开发不了简单的简单的程序。其实对于整个系统项目组干系人来说，理解系统架构是首要条件。否则，如果没有整体观念的理解，如何做好部分。
