简介
一般在企业中所搭建的系统并非天生就支持高并发，而是随着业务的发展而逐渐的被优化和重构，慢慢的支持高并发的。
所以在实际生产过程中，开发者必不可免地会慢慢接触到高并发系统，因此本章会围绕为什么要学习高并发，以及生产级系统搭建的流程展开讨论。
一、为什么要学习高并发？
提升自身及企业核心竞争力
在谈及高并发场景的技术方案时，一般程序员会有两种想法：
公司规模不大，业务清晰和单一，目前无大流量冲击，因此觉得没有必要去学习高并发系统设计。
公司业务存在大流量冲击，也存在高并发场景，但这些场景一般依赖架构师或高级工程师，认为这些都是他们去处理，自己只是一个单纯的业务开发人员，所以学习高并发系统设计的兴趣也不是很高。
上面两种情况，归根结底是自身并没有意识到学习高并发系统设计的重要性，而是因为没有接触过所以望而却步，最终无法掌握一套自己的高并发系统设计的方法论。
对于大部分小型企业或者初创型企业来说，技术架构一般比较单一，程序员只需要关注业务逻辑本身即可。例如，电商系统下单流程中，一分钟只有几单或者十几单，本身流量很小，系统足够应对，只需要关注业务本身即可：
在下单时，先查询数据库库存是否足够
如果充足，则直接创建订单
成功后锁定库存，进入支付流程
如果公司需要在节假日进行“秒杀”活动，每秒的下单请求数达到10 000个，这个10 000个请求同时对数据库查询库存，库存系统能不能承受住？如果同时需要生成10 000个订单，数据库能否承受住？如果都承受不住，该怎么解决这些问题？所以，一旦业务复杂起来，前面的设计可能会遇到很大的问题及挑战，如果没有足够的技术沉淀，可能会给公司带来巨大损失.
2. 在面试中脱颖而出
一般在面试中，面试官可能会常问：你公司系统并发量多大，有无设计高并发系统的经验？对于大流量的冲击，是如何优化的？
当前各大企业招聘时，用人部门并不是简单地考虑应聘者是否能胜任公司的业务，而是看应聘人员能否给公司带来创造更多的价值，产生更大的效益，面对琳琅满目刚毕业或刚培训出来的初级开发者，如果我们也只会单纯的CURD操作的话是远远不够的，很容易被淘汰。
如果能积累大量的学习及实践，掌握高并发系统设计，不仅能在面试中脱颖而出，而且入职后能给公司带来很大的价值，并且也可能有更大的晋升空间。
二、对比单体系统、分布式系统和微服务系统
-
单体系统
1.1 单体系统并非一无是处，在创业初期，单体系统也许是最佳的选择，投入较少的研发资源，构建出合适的当前业务的单体应用，可以帮助企业业务快速发展，从而达到抢占市场和技术试错的目的。
1.2 什么是单体系统
单体系统即一个应用程序，所有的业务代码都在这一个应用程序中，所有的表也都在一个数据库里，所涉及的相关文件都在同一个服务器上。
创业初期，为了快速进入市场，一般企业都采用单体系统。比如淘宝等电商平台在初创期都采用的是单体系统。
以上为一个传统的单体系统结构，即一个应用程序 + 一个数据库 + 一台文件服务器
1.3 单体系统面临的问题
企业快速发展后，单体系统可能会面临以下问题：
需要频繁地合并代码分支，影响项目的迭代进度。
多人协作耦合度高，测试效率进展缓慢。
开发节奏混乱，代码冲突频繁。
代码模块层次越来越复杂，业务边界变得不清晰。
项目越来越庞大，技术架构升级变得困难。
常见案例：
对于一个产品需求，可能会拉取多个分支（feature-业务A 和 feature-业务B）进行开发。在开发feature-业务B过程中，由于业务需要修改了部分功能，这部分功能涉及feature-业务A的功能，然后进行测试，并且通过了。在之后开发feature-业务A过程中进行代码拉取及合并时，可能会出现各种代码冲突，需要花费大量时间去沟通及解决。并且参与人数越多，出现代码冲突的概率更大。如果没有版本规划管理，那么这种低效的开发方式会严重阻塞产品版本迭代。
2. 分布式架构
2.1 理解分布式架构
分布式架构，是将相同或者相关的应用放在多台计算机上运行，以达到分布式计算的目的。
通俗来讲，分布式架构就是讲一个系统拆分为多个独立的应用，然后它们互相协作，组成一个整体，共同完成任务。
2.1 分布式架构局限性
2.1.1 开发者在开发应用时，需要考虑当前应用的API模块。因为，如果因为业务需要更改了相关底层逻辑，则这种修改会影响API模块，所以需要对API模块也进行对应逻辑的修改，否则已经在调用的服务会出现调用错误，影响线上产品。
2.1.2 外部的服务需要依据自己的业务向服务提供方提出相应的小需求。服务提供方可能只是改动了API模块，但是从整体来说则需要测试并重新部署一遍，影响服务的稳定性。
（PS：在分布式架构下，很可能出现很多业务功能的重复开发，即所谓的“重复造轮子”，造成开发资源的浪费。）
所以，分布式架构系统更适合与业务关联性低、耦合少的业务系统。例如企业内部管理系统（如进销存系统和CRM系统）适合搭建成分布式架构。
3.1 微服务架构
3.1.1 理解微服务架构
微服务是由单一应用构成的小型服务，拥有自己的进程与轻量化处理。
微服务依据业务功能设计，以全自动的方式部署，与其他微服务使用HTTP API进行通信。
微服务会使用最小规模的集中管理技术，如Docker。
微服务可以使用不同的编程语言和数据库。
3.1.2 微服务系统构造
微服务系统就是将复杂的单体系统中的模块按照某种规则进行拆分，这些被拆分出来的模块被独立部署在相对较小的服务器集群上。独立部署的模块彼此之间使用远程调用的方式来完成整个业务的处理。这些被独立部署的模块就是微服务，而这样的应用架构就是微服务架构。
单体系统 -> 分布式架构 -> 微服务架构 演变图
左侧的单体应用在扩展时，采用整体应用扩展的方式 右侧的微服务架构在扩展时，采用的是以服务为单位的扩展方式 3.1.3 微服务架构的问题
（1）增加了复杂度
从单个应用演变到多个应用，不仅会带来服务数量的增加，也会带来交互模式的变更。
（2）服务间的通信会变得复杂
引入微服务架构后，系统变成了一个分布式系统。在分布式系统中，应用之间是通过进程进行通信的，如采用REST 或 RPC框架调用的方式进行通信。这种通信方式要求调用端需要有完善的策略以应对服务调用不成功的情况，因为服务调用者先得明确知道服务提供者具体部署在哪台机器，然后找到对应的机器进行通讯。同时如果服务提供者出现异常或宕机，则服务调用者如何实时感知等是很复杂的。
（3）在落地微服务时，微服务边界的划分增加了 代码实现 的复杂性
微服务边界划分是微服务设计的【难点】，划分的好坏直接决定着整个微服务架构的好坏，会影响整个产品的推进进度：
a. 如果服务颗粒度划分过粗，则随着业务复杂度的上升，系统又会是一个庞大的单体应用。
b. 如果服务颗粒度划分过细，则会出现数量很多的服务，这样会增加服务运维及监控的成本，过多的服务会使得调用链变得复杂，直接影响整个系统的性能。在划分一段时间后，如果觉得不合适，则重组服务的工作量巨大且风险很高。
（4）保持数据一致性非常复杂
微服务架构中服务可能使用的是不同的数据库，包括关系型数据库和非关系型数据库，要在这些数据库之间保持数据一致性是非常复杂的。
（5）对运维团队和开发团队都提出了更高的要求
每个服务都有自己的实现方式，且服务数量很多，所以，运维团队不仅需要维护种类繁多的数据库和消息中间件，还需要应对持续集成和持续部署的挑战；开发团队需要具备微服务开发经验，开发人员成本随之提高。
（6）开发流程复杂
建议将微服务架构的团队按照服务来划分团队，每个团队负责一个或多个微服务的开发、测试、构建及运维等。但是在开发流程上，瀑布式的开发流程并不适用于微服务开发，微服务开发应该采用敏捷软件开发流程。
本章节整理分享了高并发系统中单体系统、分布式系统、微服务架构系统等介绍，以及学习高并发系统设计思想的必要性，如果觉得可以的话，可以点赞、分享呀~感谢各位小伙伴了
关注公众号：Java极客思维
