一提到高并发性，很多人就会头疼。 我不太清楚为了搭载高同时性该怎么设计。 虽然经常听到集群、负载均衡等说法，但是不知道具体的体系结构是什么样的，很棘手。 然后，我们将逐步分析高并发性体系结构是如何形成的。
一、常用基本概念：
1、分布：分布一般指软件级的布置，例如，可以将一个APP应用同时布置在多台机器上执行，以分布压力。
2、集群(Cluster )集群指的是使用多个设备来执行相同的服务。
3、高可用性)高可用性是指多台机器同时提供一项服务时，一台机器发生故障后，其他机器继续代替故障机器提供正常服务。
4、负载均衡：负载均衡相当于指挥官，客户端发出请求后，指挥官分配应该去往哪个服务器，达到可以平均分配各服务器的压力值。
有了以上的基本认识，我们来看看独立架构是如何逐步升级并融入这些感想的。
二、架构晋级之路
1、独立体系结构：
从上图中可以看到，所有服务都在同一台计算机上运行。 这也是网站最初的样子，用户少，业务也比较简单。
2、服务分割：
随着用户的增加，多台服务器同时消耗服务器资源导致响应变慢。 将每个服务划分为不同的服务，以减少资源消耗问题。
3、缓存服务部署：
过了一会儿，我发现数据存在瓶颈。 使用缓存服务减轻数据库压力，然后使用redis或memcache。
4、初步负荷平衡：
通过一些监控手段，我们发现一台服务器无法满足业务层的承载能力。 进行横向扩展，将一台机器增加到多台，同时利用NGINX负载均衡机制传输到后端不同的业务服务器，利用缓存机制共享会话。
5、数据库读写分离：
在业务层的服务器得到充分支持后，如果发现数据库层又遇到了一定的瓶颈，则进行读写分离的数据库部署。 一般的主库只负责读取，而库只负责写入，这会给客户端的操作带来一定的麻烦，所以这时需要同步部署数据库中间件来简化数据库操作。 我个人推荐Mycat/sharding-jdbc这两种。 利用中间件可以很容易地实现分区表。
6、使用F5或LVS :
随着后端搭载能力的提高，NGINX的搭载能力明显变得不足。 可以部署F5或LVS，以便在多个NGINX上工作。 F5是硬件LVS是软件，他们都可以实现负载均衡。 性能上F5比LVS高，但价格高。 需要备用节点，因为LVS是独立的软件，如果LVS所在的服务器停机，将无法访问整个后端系统。 您可以使用keepalived软件模拟虚拟IP，并将虚拟IP绑定到多个LVS服务器。 当客户端访问虚拟IP时，路由器会将其重定向到实际的LVS服务器，当主LVS服务器关闭时，keepalived软件会自动更新路由器中的路由表，并将虚拟IP发送到另一个普通LVS服务器
7、DNS绑定多IP :
当F5或LVS仍然无法承受时，需要通过DNS将多个IP绑定在一起并轮换到不同的F5或LVS节点以分散压力。 在数据库级别，需要在许多计算机上分散压力。 此时，我们几乎可以承载非常高的并发量，APP也一定丰富了。 将这么多APP应用程序放在一起显然不合适，需要将业务细分。
8、拆分APP应用程序：
对于大型站点，可以将整个站点的业务划分为不同的模块，每个模块将一个站点划分为多个APP应用程序，并对每个APP应用程序进行单独的部署和维护。
分割APP应用程序后，添加了NoSsql、搜索引擎等，提高了APP应用程序的各项能力。 当数据库中的数据达到一定规模时，数据库往往不适用于复杂的查询，而只能满足普通查询的场景。 在统计报告场景中，如果数据量较大，则不一定会出现结果，并且执行复杂查询会导致其他查询变慢。 数据库天生不适用于全文搜索和可变数据结构等场景。 因此，需要针对特定场景部署适当的解决方案。 对于大文件存储，可以通过分布式文件系统HDFS解决；对于key value类型的数据，可以通过HBase和Redis等解决方案解决；对于全文搜索场景，可以通过ElasticSearch等搜索引擎解决；多维
析场景，可通过Kylin或Druid等方案解决。9、微服务：
随着业务拆分，整个系统越来越大，应用的整体复杂度呈指数级增加，部署维护越来越困难，我们将各业务重复的模块拆分成微服务，由各服务统一提供服务，应用和服务之间通过HTTP、TCP或RPC请求等多种方式来访问公共服务，每个单独的服务都可以由单独的团队来管理。现在主流的微服务框架基本都具备服务治理、限流、熔断、降级等功能，提高服务的稳定性和可用性。
10、引入ESB企业服务总线
通过ESB统一进行访问协议转换，应用统一通过ESB来访问后端服务，服务与服务之间也通过ESB来相互调用，以此降低系统的耦合程度。
11、容器化：
docker是一个容器，可以利用容器快速的部署系统，同时利用K8S来管理容器。
三、常见疑惑
1、架构的调整是否必须按照上述演变路径进行？
不是的，以上只时列举了在晋级过程中所需要的知识点及思路，在实际场景中需要结合具体需求来进行演变，需要解决什么样的问题就把哪一部分的内容加入现在的架构里，切记太过死板。
2、对于将要实施的系统，架构应该设计到什么程度？
够用就好，一个简单业务没必要搞成非常复杂的架构，但是也要为以后考虑，尽量留有扩展架构的接口以便不备之需。对于不断发展的系统，如电商平台，应设计到能满足下一阶段用户量和性能指标要求的程度，并根据业务的增长不断的迭代升级架构，以支持更高的并发和更丰富的业务。
3、在设计过程中需注意什么？
其实也没有什么特别需要注意的，一般情况下如果你亲自去设计一个架构的话往往会不知不觉的考录很多方面。如最重要的一点是如何兼容新旧版本劲量做到无感升级，如出现问题如何能快速回滚到旧版本，在什么环节增加怎样的监控手段，如何保证系统的稳定运行，是否能够友好的支持扩展性等等。