读《服务端高并发分布式架构演进之路》有感

起始

原文在这里 https://segmentfault.com/a/1190000018626163
起初，从网络容器和数据库在同一个机器，开始。

1

【问题】
服务器和数据库之间资源竞争，随着用户增长，数据库成为瓶颈

【解法】
数据库和网络服务器分开，服务器使用本地缓存，同时使用外部分布式缓存

2

【问题】
随着用户增长，服务器的响应时间成为瓶颈

【解法】
使用 Nginx 来进行反向的负载均衡

3

【问题】
单机数据库成为性能瓶颈

【解法】
数据库读写分离，分成读库和写库
Mycat

4

【问题】
业务增多，不同业务之间访问量有差距，竞争数据库资源

【解法】
分库，不同业务数据分到不同的数据库
（跨业务表怎么办？）

5

【问题】
单机写库成为性能瓶颈

【解法】
分表，还可以分小时表，使得数据请求可以均匀分发到多台服务器上，支持水平扩展

6

【问题】
Nginx成为性能瓶颈

【解法】
使用 LVS 配合 keepalived 实现更高量级的接入

7

【问题】
由于LVS也是单机的，随着并发数增长到几十万时，LVS服务器最终会达到瓶颈，此时用户数达到千万甚至上亿级别，用户分布在不同的地区，与服务器机房距离不同，导致了访问的延迟会明显不同

【解法】
在DNS服务器中可配置一个域名对应多个IP地址，每个IP地址对应到不同的机房里的虚拟IP。当用户访问www.taobao.com时，DNS服务器会使用轮询策略或其他策略，来选择某个IP供用户访问。此方式能实现机房间的负载均衡，至此，系统可做到机房级别的水平扩展，千万级到亿级的并发量都可通过增加机房来解决，系统入口处的请求并发量不再是问题。

8

【问题】
随着数据增多到一定的规模时，数据库就不适合负责查询复杂数据了。

【解法】
引入合适的解决方案，解决海量数据的索引和查询问题，特别是全文检索问题。

9

【问题】
业务维度能够极大扩充，随之而来的是一个应用中包含了太多的业务代码，业务的升级迭代变得困难

【解法】
按照业务板块来划分应用代码，使单个应用的职责更清晰，相互之间可以做到独立升级迭代。这时候应用之间可能会涉及到一些公共配置，可以通过分布式配置中心Zookeeper来解决。

10

【问题】
不同业务之间存在共用的模块，或者相同的代码，导致公共功能升级时，全部代码都需要跟着升级。

【解法】
引入微服务，同时使用一些框架来进行服务治理，限流，熔断等提升服务稳定性和可用性

11

【问题】
不同服务的接口访问方式不同，应用代码需要适配多种访问方式才能使用服务，此外，应用访问服务，服务之间也可能相互访问，调用链将会变得非常复杂，逻辑变得混乱

【解法】
通过ESB统一进行访问协议转换，应用统一通过ESB来访问后端服务，服务与服务之间也通过ESB来相互调用。总之，就是 SOA 化。

12

【问题】
随着应用和服务增多，运行环境，运维等问题比较突出。同时有的业务，比如大促，需要较强的动态扩缩能力。

【解法】
引入容器化docker和容器管理服务k8s

13

【问题】
物理机器的资源浪费

【解法】
搭建公有云，活用资源