我们的应用系统是如何支撑千万级别用户的

《我们的应用系统是如何支撑千万级别用户的》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、我们的应用系统是如何支撑千万级别用户的背景我现在负责的项目是一个合同型项目，也就是甲乙方关系。目前我们系统累计用户数约2500万+，日活跃200万+。而今年客户的KPI指标是用户总数翻一翻。而刚好这几天我需要给客户汇报一份关于“如何支撑数千万级别用户”的系统报告。借此机会，也顺带多写一份分享心得。前序从项目性质可以看出，我们公司就是一个IT服务企业，既然是服务，那么客户的满意就是我们前进的动力，注意是客户而不是用户。客户提出这个汇报要求，无非要的就是我们能否协助他们完成KPI的信心。再进一步说，就是我们开发的

2、系统能否很好地支撑他们达到业务和用户的KPI目标。首先我会想到的一点是，今年将会是一个怎样的数千万用户级别系统，也就是说这个数千万用户系统的背后需要支撑什么样的业务目标。例如数千万用户的秒杀和数千万用户的查询还是有天大的区别。按照我对该行业客户的了解，我是无法从中得知太多有利用价值的商业信息。所以他们实际要的就是一个“能快速响应、随机应变且能支撑数千万用户的系统”。能快速响应意味着我们要随时能跟上他们紧急的需求新增或紧急的需求变更；随机应变也就意味着他们想做什么就做什么且不能拒绝；数千万用户就是一个代表并发的

3、量词，他不会告诉你这数千万用户什么时候一个个来或什么时候会一起来。客户对系统的要求也不多，也就“稳定、灵活、可扩展和敏捷开发”四个要求。下面就来说说我将会通过什么样的手段来满足客户的欲望。主题从宏观角度看，一个系统并非只是一个硬件+软件的集合那么简单，它还涉及到其它方方面面的因素，这些因素间相互紧密关联，比如公关做不好或者业务方向偏轨，系统再好，也无补于事。从微观角度看，一个系统并非只是需求、开发、测试的事情，我们还要考虑运维、实施等项目阶段成员的感受。一个项目的最大难度可能不是开发，或许可能是运维。一个项目

4、的复杂度会随着时间的迁移或者骨干人员的变动而指数增加。从这些方面去考虑，这个系统必须保持足够的“简单”，才能降低项目的各种成本。当然，越简单越复杂，最终依赖的还是一个“简单”的团队。简单的框架从上图得知，该系统是一个面向服务体系结构（SOA）系统，也是“简单”的首先。该系统主张的是把所有服务组件化，最大的组件粒度是平台，例如运营平台、外部服务支撑平台、内部服务支撑平台等。而最小的组件粒度是服务。组件化也是系统灵活性和可扩展性的必要因素。平台垂直分为入口层和业务层，下面分别介绍一下。入口层入口层的主要职责就是充

5、当业务系统门卫，检查业务请求的合法性，各检查组件之间松耦合，没有任何关联，随时能删能减，不会影响整个系统的稳定性。业务层顾名思义，业务层的主要职责负责对业务的逻辑处理，并响应用户业务请求。该业务层主要包含参数验证、逻辑处理、响应请求三大步骤。一个业务实体代表一种服务，各业务实体之间同样是松耦合，没有任何关联，缺少任何一种业务都不会导致系统的崩溃。辅助组件工具包这个工具包包含各种通用辅助组件，主要职责是辅助入口层和逻辑层各组件的执行，例如数据库操作组件、Redis操作组件等。该系统的主要特点有:1、控制业务粒度

6、复杂度没有不能简单的功能，只有乳臭未干的设计者。一个业务也相当于一个组件。一个过于复杂的组件无论从运维还是性能来说都是噩梦的开始。如果每一个组件都有它的“自管”能力，后续的运维工作就会大大的降低。2、控制线程栈的大小一个业务线程栈过大也就意味着线程执行时间不会太短，对于一个互联网应用，每一毫秒都是系统体验的关键所在。3、控制系统透明度所谓的透明度也就是线程栈的透明度，就是每个程序员都必须非常清晰的理解自己的线程栈将会如何运行，在什么地方会存在异常风险，如何处理等操作手段。也因为这样，整个系统没有使用任何其它的

7、“业务逻辑开源框架”，大大地降低了开发人员的学习成本和压力，也大大地提高了系统的可控性。可以让程序员接触更多基础的东西。包括数据库的操作也是需要开发人员自己亲手去写业务的SQL语句，并保证SQL语句的性能消耗。当然，这也需要开发人员对数据库有一定的了解程度。4、控制业务验证对任何业务的请求都必须保持不可信任的态度，这也是业务实例的第一步就是做请求参数验证的必要性。服务是对外的，谁也不敢确保没有恶意的攻击，这个一个系统必须考虑的边界因素。否则系统毫无安全性可言。简单的部署部署同样遵守组件化、控制业务复杂粒度等原

8、则。确保每个垂直的部署都是一个独立的业务集群，每个业务集群必须控制好业务的复杂度，好比如一个细胞成长到一定程度会自动分裂出两个细胞，否则胀爆是唯一的后果。从以上架构图中左边的两个箭头和系统特性得知，该系统可横向平台分解部署或同一平台中业务分解部署，大概的部署效果如下图所示：如果资源和业务允许，各垂直集群硬件的独立性也是必要的，尽可能确保各部署集群之间的松耦合。对于实施人员来说，每个集群业务的部署，只