国人人口基数注定了面向2C架构设计逃不开高性能并发的需求，作为技术负责人（架构师）在这方面的考量是决定应用成功运营的关键因素。高性能并发的需求根源在于资料/数据的相关关联性和集中性，这里所描述的资源/数据包括但不局限于:
- 宽带资源
- 静态资源（图片、Html、CSS等）
- 数据库静态数据（相对）
- 数据库动态数据
- 应用服务资源
高性能并发架构设计的基本要求：1、对资源/数据合理梳理并分类；2、纵向层面上让数据/资源提升，在横向层面上合理分布，在实际应用中数据/资源提升后仍需要考虑横向层面上的合理分布。3、选择合适的实施技术。
（写到这里，忽然联想到国内教育资源、医疗资源等等，同样存在相对集中性的特点，如何解决针对这些资源的高性能并发问题，也许两者之间些许相通之处）
- 宽带资源（横向）
高并发在宽带资源方面直接表现为高流量、高分布，单节点存在出入口流量限制和路由造成的实际延迟的问题。根据地区特点实施多节点部署是通用的作法，多节点部署还可以实现容灾的需求。
这里特别提及一个名词“两地三中心“。“两地三中心” 的技术架构最早在银行和金融行业应用实施，但一般都只有一个机房提供服务，其他的灾备机房仅同提供服务的生产机房进行数据复制，这种冷备的模式并不适用于互联网业务。
异地多活在一定程度上可以有效地提高产品和业务应对区域故障的能力，确保出现故障的情况下绝大多数用户的核心体验可用。但是不可否认，异地多活的实施成本和代价也是非常高昂的，尤其是面对迭代节奏非常快的互联网业务，所以异地多活适用于业务模型已经趋于稳定的应用。但即便如此，在实施过程中，也要有针对性地选择核心和关键业务，并不是所有的业务都需要异地多活的部署。
多节点的宽带流量调配需要熟悉GSLB（Global Server Load Balance）的技术内容。
- 静态资源（纵向）
静态资源主要指图片、html、CSS、Js等，传统概念这些资源集中由Web服务器提供。实现静态资源的提升一般采用如下两种技术手段：
- 在WEB服务器之前，部署反向代理缓存服务器。这里推荐Nginx+Squid的技术组合，动态资源由Nginx直接转发到应用服务器，而静态资源文件，如jpg，png，js等转发到Squid，由Squid负责向Web服务器访问。
- 选择第三方CDN。第三方CDN拥有完整的CDN网络，其缓存服务器位于网络的边缘，距用户仅有"一跳"之遥。同时，代理缓存是内容提供商源服务器的一个透明镜像。这样的架构使得CDN服务提供商能够代表他们客户，即内容供应商，向最终用户提供尽可能好的体验，而这些用户是不能容忍请求响应时间有任何延迟的。
- 数据库静态数据（纵向）
这类数据相对不变，多数用于检索，比如首页的推荐文章列表等，这些数据访问频次高，在数据库前部署缓存服务来提升这部分数据，将直接减少对数据库的穿透访问。
Redis是作者常用也是推荐的技术实现，其拥有速度快、持久化 、支持多种数据结构、支持多种编程语言 、功能丰富（事务、流水线、发布/订阅、消息队列）、高可用及分布式等特点。Redis不仅可用于数据库静态数据的提升外，还可使用于以下场景：
1、会话缓存（最常用）
2、消息队列，比如支付
3、活动排行榜或计数
4、发布、订阅消息（消息通知）
- 数据库动态数据（横向）
这部分数据是整个应用的核心所在，除了常规的服务器性能优化外，基于服务器的运算能力的天花板限制是造成并发能力不足的根源。实际有效的解决办法是根据业务和数据特点对数据库存储进行优化：
- 分库
- 分表
- 主从读写分离
对于数据业务简单的应用，确定规则就可以直接实施，原则上无需选择中间件来处理，作者在这方面并没有实际经验，当当自研的数据库中间层 Sharding-JDBC建议大家可以拿来研究。
- 应用服务资源（横向）
简单应用会把逻辑整合在一个应用中，稍复杂会分应用处理并部署在不同的服务上实现，微服务的提出更加有效地在分布式应用架构上解决了此问题。
微服务推荐Dubbo+Docker，它是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。其主要优点包括：
1、透明化的远程方法调用
2、软负载均衡及容错机制
3、服务注册中心自动注册 & 配置管理
4、服务接口监控与治理