前一段时间，有个网警朋友与我聊天，聊到web系统的并发产生与对应的解决方案。因此我专门写了一篇文章，分两个章节来说此事的。第一部分主要讲服务架构，第二部分主要讲事实中常见的并发产生场景。
首先说服务架构，服务架构主要分微服务架构与分布式架构。下面我就从他们的发展历史、定义与特点、应用与优势及对应的架构演变过程这几个方面，最后做一个简单总结。
一、发展历史
分布式理论奠基与1980~1990年，CAP定理（一致性、可用性、分区容错性）和BASE理论（基本可用、软状态、最终一致性）的提出，为分布式系统设计提供了理论支撑，直到2000~2010年，Google的GFS、MapReduce和BigTable论文引领了大数据分布式处理，之后就开始把分布式技术在企业级应用的普及。
微服务早在2005年被Peter Rodgers 博士在 2005 年度的云计算博览会提出，指的是一种专注于单一职责的、语言无关的、细粒度web服务。最初的微服务可以说是SOA发展催生的产物。直到2012年波兰克拉科夫提出，指的是一种单一服务职责、康威定律(企业组织机构)、自动扩展、领域驱动设计等原则，却只字未提 SOA。(微服务真正的崛起是在 2014 年，专为中国而造。)
淘宝采用的是微服务架构、天猫、拼多多、京东采用的是分布式架构。
二、定义与特点
1、分布式架构
1.1、定义
由多台独立计算机（节点）通过消息传递进行通信和协调的系统，彼此之间没有主从之分，共同对外提供服务，但对用户来说就像是一台计算机在提供服务一样
1.2、特点
分布性：节点在地理位置和网络环境中分散部署，这使得系统能够更好地利用资源，提高整体的可用性和容错性
并发性：多节点并行处理任务，需要解决资源竞争和数据一致性等问题。例如，使用Paxos算法解决数据一致性问题，使用消息队列异步处理资源或是事务
无全局时钟：节点间依赖消息传递，难以严格定义事件顺序，需要使用向量时钟等机制来处理时间同步问题
故障独立性：部分节点故障不影响整体可用性，提高了系统的稳定性和可靠性
可扩展性：随着需求的增加，可以通过增加新的节点来处理更多的请求，而不需要升级单个节点的硬件或软件
分布式系统通过水平扩展（Scale-out）而非垂直扩展（Scale-up）提升性能，解决了单点性能瓶颈问题
2、微服务架构
2.1、定义
是一种将应用拆分为多个小型、独立的服务的设计模式，每个服务专注于单一功能，并通过轻量级协议进行通信
2.2、特点
单一职责：每个服务围绕特定业务功能设计，如订单处理、支付等，确保高内聚和松耦合
独立性：每个服务可以独立部署、更新和扩展，这意味着可以单独运行、更新和扩展某个服务，而不需要重启整个系统
松耦合：服务之间通过API（如REST、gRPC）进行通信，减少相互依赖，提高系统的灵活性和可维护性
分布性：服务运行在多台服务器或容器上，支持水平扩展和负载均衡
模块化：服务按业务边界划分，而不是技术边界，使得系统更加灵活和可维护
微服务系统离不开容器及网络负载
三、应用与优势
1、分布式架构的应用
云计算：分布式系统是云计算平台的核心技术之一，提供弹性可扩展的计算资源和服务，满足用户按需分配、自动扩展的需求
大数据处理：分布式系统能够处理和分析大规模数据集，通过并行计算和数据分布管理技术提高处理效率
实时数据处理：分布式流处理系统如nginx Kafka等，适用于需要高效处理实时数据的场景
区块链应用：在区块链领域，分布式架构通过去中心化的设计，增强了系统的安全性和透明度，使得交易数据通过多个节点共同维护和验证，提高了系统的稳定性和可靠性
大型电商及活动：并发控制是分布式架构的优势之一
2、分布式架构的优势
高可靠性：通过冗余设计和容错机制，有效应对单点故障，确保系统持续稳定运行
可扩展性：根据需求动态增减节点，满足不断变化的系统需求，轻松应对日益增长的计算、存储和访问需求
高性能：任务拆分为子任务，分配给不同节点并行计算，显著提高处理效率，适用于大数据处理、复杂计算等场景
资源共享：节点共享各类资源，减少资源重复建设，提升整体利用率，降低系统成本
高可用性：通过冗余和故障转移机制，确保系统在部分节点故障时继续提供服务
3、微服务架构应用
在B2B及SaaS平台源码开发中，微服务架构的应用主要体现在将平台拆分为多个独立的服务模块，每个模块负责特定的业务功能，如商品管理、订单管理、支付管理、用户管理等。这些服务模块之间通过RESTful API进行通信，实现了平台功能的解耦和模块化，从而提高了系统的灵活性和可扩展性
4、微服务架构优势
提升开发效率：团队可以围绕特定服务进行并行开发，每个服务可以使用最适合的技术栈，缩短开发周期，加快市场响应时间
独立部署与扩展：每个服务可以独立部署和更新，只需对需要修改的服务进行操作，降低了部署风险，并允许针对负载高的服务进行独立扩展
促进技术多样性：不同的服务可以使用不同的编程语言和技术栈，团队成员可以根据兴趣和专业技能选择项目，增加了工作的灵活性和员工的满意度
增强系统可维护性：系统被拆分成多个小的服务，每个服务的代码量较少，开发人员可以更轻松地理解和管理代码，排查和修复故障的速度更快
提高系统的容错性：单个服务的故障不会影响其他服务，通过服务熔断、重试等机制，有效控制故障传播
四、架构演变过程
只有极少数企业真正做到要区分分布式架构与微服务架构(除了做SaaS平台的)，因为架构其实是一种思想，或者是叫一种开发框架，用来支持动态网站、网络应用程序及网络服务的开发。而这种思想一般分为四种阶段。单机(单体)架构阶段、集群架构阶段、服务架构阶段、分布式架构或是微服务架构阶段。
1、分布式架构走向图
1.1、单机架构
1.1.1、什么叫单机架构：单机架构也是传统架构，就是单台服务器承载所有服务
1.1.2、什么叫服务：服务的统称被称作可执行、可翻译、可存储等成熟基于操作系统而运行的程序软件
1.1.3、nginx代理服务：专门做指派工作的
1.1.4、php执行服务：真正做事情的。如果需要读取MySQL数据库中的数据，他就会去MySQL中读取，如果需要读取Redis缓存服务中的数据，他就会去Redis中读取，如果需要将文件上传到oss服务器中，他也是可以操作的，并返回结果
1.1.5、架构执行流程：用户通过手机或是台式机的app或是浏览器直接打开或是访问，前端程序根据当前页面的请求接口发送指令到指定的域名解析商(服务商)，而指定的域名解析商(服务商)把对应的请求指令转发到对应的解析服务器中，解析服务器里安装的nginx、apache、tomcat接到指令就立即创建资源句柄成功后将执行转发到nginx+php执行服务器中，nginx+php执行服务开始去执行，需要读取缓存的情况下，就去Redis中，需要读取MySQL数据的情况下，就去MySQL中，等业务操作完毕后返回结果给nginx，nginx接收到结果之后释放资源句柄并原路返回。
1.1.6、特殊情况：我通常在nginx代理服务器上会加了lua+redis，专门做黑白名单处理的(也就是安全)；oss文件存储服务器，我正常的操作方法是内网写入，外网读取；
1.2、集群架构
1.2.1、什么叫集群架构：集群架构也是传统架构，就是单台服务器无法承载所有服务，根据慢查询进行服务拆分
1.2.2、什么叫服务：服务的统称被称作可执行、可翻译、可存储等成熟基于操作系统而运行的程序软件
1.2.3、nginx代理服务：专门做指派工作的
1.2.4、php执行服务：真正做事情的。如果需要读取MySQL数据库中的数据，他就会去MySQL中读取，如果需要读取Redis缓存服务中的数据，他就会去Redis中读取，如果需要将文件上传到oss服务器中，他也是可以操作的，并返回结果
1.2.5、架构执行流程：用户通过手机或是台式机的app或是浏览器直接打开或是访问，前端程序根据当前页面的请求接口发送指令到指定的域名解析商(服务商)，而指定的域名解析商(服务商)把对应的请求指令转发到对应的解析服务器中，解析服务器里安装的nginx、apache、tomcat接到指令就立即创建资源句柄成功后将执行转发到nginx+php执行服务器中，nginx+php执行服务开始去执行，需要读取缓存的情况下，就去Redis中，需要读取MySQL数据的情况下，就把读取的指令(DML SQL语句)发送给mycat中间件，而mycat中间件接收到指令后自动查找对应规则的数据库数据返回，如果需要往MySQL数据库中写数据的情况下，就直接往主数据中写，数据库会自动同步到从数据库中，等业务操作完毕后返回结果给nginx，nginx接收到结果之后释放资源句柄并原路返回。
1.2.6、特殊情况：我通常在nginx代理服务器上会加了lua+redis，专门做黑白名单处理的(也就是安全)；oss文件存储服务器，我正常的操作方法是内网写入，外网读取；这种情况下，基本上是请求量与数据量或是资源句柄不够用的情况下搭建的，到这一地步的时候，公司的发展到达一定的高度啦，如果没有达到的情况下，建议放弃产品。但是同时也要明白一件事情，这种在锁库存的场景下作用根本不大且同样也会出现数据写入后无法及时读取到；
1.3、服务架构
1.3.1、什么叫服务架构：基础服务架构也是传统服务架构的一种方式，就是将后端的api按照请求量的大小进行拆分成多台对外的代理服务。这样就可以快速分离各端请求路线
1.3.2、什么叫服务：服务的统称被称作可执行、可翻译、可存储等成熟基于操作系统而运行的程序软件
1.3.3、nginx代理服务：专门做指派工作的
1.3.4、php执行服务：真正做事情的。如果需要读取MySQL数据库中的数据，他就会去MySQL中读取，如果需要读取Redis缓存服务中的数据，他就会去Redis中读取，如果需要将文件上传到oss服务器中，他也是可以操作的，并返回结果
1.3.5、架构执行流程：用户通过手机的app或是电脑浏览器直接访问，前端程序根据当前页面的请求接口发送指令到指定的域名解析商(服务商)，而指定的域名解析商(服务商)把对应的请求指令转发到对应的解析服务器中，解析服务器里安装的nginx、apache、tomcat接到指令就立即创建资源句柄成功后将执行转发到nginx+php执行服务器中，nginx+php执行服务开始去执行，需要读取缓存的情况下，就去Redis中，需要读取MySQL数据的情况下，就把读取的指令(DML SQL语句)发送给mycat中间件，而mycat中间件接收到指令后自动查找对应规则的数据库数据返回，如果需要往MySQL数据库中写数据的情况下，就直接往主数据中写，数据库会自动同步到从数据库中，等业务操作完毕后返回结果给nginx，nginx接收到结果之后释放资源句柄并原路返回。
1.3.6、特殊情况：我通常在nginx代理服务器上会加了lua+redis，专门做黑白名单处理的(也就是安全)；oss文件存储服务器，我正常的操作方法是内网写入，外网读取；这种情况下，基本上是请求量与数据量或是资源句柄不够用的情况下搭建的。但是同时也要明白一件事情，这种在锁库存的场景下作用根本不大且同样也会出现数据写入后无法及时读取到；个人建议这种架构只能应急使用，毕竟到达这一地步的时候，是需要彻底解决安全的问题
1.4、分布式架构
1.4.1、什么分布式架构：分布式架构是web架构中顶级架构啦，市面上Java框架对应的微服务架构其实就是传统的分布式架构。只不过是中国的那些所谓的专家、教授定义出来的。分布式架构就是把我们常听到的平台端、客户端、小程序端等页面对应的共有数据整理成一个独立系统(包括数据库、缓存及访问流程)。比如电商平台里面有会员系统、商品系统、物流系统、订单系统、商家系统、支付系统等，而商品系统里面又有分类业务系统、产品列表业务系统、产品详情业务系统、活动详情业务系统、搜索列表业务系统等。分布式架构也称分布式系统。他在业务逻辑上面需要流程化管控，比如还是以电商为例，用户登录后才能加入购物车及立即下单购买，下单购买按钮点击后需要填写收货地址，然后点击立即下单后，后端添加好用户订单后返回支付参数让前端调起第三方支付系统。后端接收到第三方支付系统的回调指令后加入消息队列生产者(rabbitmq、kafka)，消息队列消费者验证信息的正确性后采用ws通信的方式告知前端《支付完成》并告知下一个流程，开始处理数据。
1.4.2、什么叫服务：服务的统称被称作可执行、可翻译、可存储等成熟基于操作系统而运行的程序软件
1.4.3、nginx代理服务：专门做指派工作的
1.4.4、php执行服务：真正做事情的。如果需要读取MySQL数据库中的数据，他就会去MySQL中读取，如果需要读取Redis缓存服务中的数据，他就会去Redis中读取，如果需要将文件上传到oss服务器中，他也是可以操作的，并返回结果
1.4.5、架构执行流程：用户不管是通过浏览器访问还是通过APP访问，如果是需要登录的情况下，前后端规定的流程是前端第一步调用中控台，也就是商城系统里面的会员系统。只有登录了以后才能操作下一步；如果是非登录的情况下，前端是根据用户操作的页面路由跳转到指定的页面中，而每个页面都有指定的接口请求，获取动态数据或是对应的静态数据。而服务器是接到不同的域名后反向代理到指定的服务集群，服务集群接到不同的指令后，会按照系统里面规划好的流程去获取数据，如果需要获取MySQL数据就去MySQL从库中读取数据，而需要写入数据到数据库中的时候，是直接写入到主MySQL数据库中，而从库是检测主库发生变化后主动从主库中同步数据到从库中。如果需要从Redis中读取数据就从Redis中去读取数据，而需要写数据时，也是写入到主库中，某一台从库上的哨兵检测到主库发生变化后，就会立即从主库同步数据到从库中。
1.4.6、特殊情况：我通常在nginx代理服务器上会加了lua+redis，专门做黑白名单处理的(也就是安全)；oss文件存储服务器，我正常的操作方法是内网写入，外网读取；这种架构即解决了网络安全又解决了服务安全，因为有备用机在720小时待命，又解决了消峰(也是处理请求等待问题)。网络层面分为了入网及出网；并发处理采用的是快速接收指令及返回，异步通知发送指令者；这种架构最大的问题是开发难度提高了，因为需要懂业务流程、提前规划业务流程。这种服务架构很费钱。这种一般服务器在30台，再加上5到10台运维服务器，费用不低。网络带宽基本上是几百兆。专门出网的服务器基本最低每台为10M，而入网的服务器基本常用带宽是50M到100M之间；最大的好处是安全极高，拓展快速，不用担心查询慢，访问慢，被人盗数据等问题。因为运维者都不一定知道哪张表或是哪个库在哪台服务器上；
2、微服务架构走向图
2.1、单机架构
2.1.1、什么叫单机架构：单机架构也是传统架构，就是单台服务器承载所有服务，这一步基本上很少用到网络负载
2.1.2、什么叫服务：服务的统称被称作可执行、可翻译、可存储等成熟基于操作系统而运行的程序软件
2.1.3、nginx代理服务：专门做指派工作的
2.1.4、php执行服务：真正做事情的。如果需要读取MySQL数据库中的数据，他就会去MySQL中读取，如果需要读取Redis缓存服务中的数据，他就会去Redis中读取，如果需要将文件上传到oss服务器中，他也是可以操作的，并返回结果
2.1.5、架构执行流程：用户通过手机或是台式机的app或是浏览器直接打开或是访问，前端程序根据当前页面的请求接口发送指令到指定的域名解析商(服务商)，而指定的域名解析商(服务商)把对应的请求指令转发到对应的解析服务器中，解析服务器里安装的nginx、apache、tomcat接到指令就立即创建资源句柄成功后将执行转发到nginx+php执行服务器中，nginx+php执行服务开始去执行，需要读取缓存的情况下，就去Redis中，需要读取MySQL数据的情况下，就去MySQL中，等业务操作完毕后返回结果给nginx，nginx接收到结果之后释放资源句柄并原路返回
2.1.6、oss文件存储服务器，我正常的操作方法是内网写入，内网读取
2.2、集群架构
2.2.1、什么叫集群架构：就是传统集群架构，就是通过网络负载分发到所有执行服务服务器上 (有轮询、权重等方式)，程序根据对应的配置去操作对应数据库集群
**2.2.2、**什么叫服务：服务的统称被称作可执行、可翻译、可存储等成熟基于操作系统而运行的程序软件
2.2.3、nginx代理服务：专门做指派工作的
2.2.4、php执行服务：真正做事情的。如果需要读取MySQL数据库中的数据，他就会去MySQL容器中读取，而容器会到MySQL中操作，如果需要读取Redis缓存服务中的数据，他就会去Redis中读取，如果需要将文件上传到oss服务器中，他也是可以操作的，并返回结果
2.2.5、架构执行流程：用户通过手机或是台式机的app或是浏览器直接打开或是访问，前端程序根据当前页面的请求接口发送指令到指定的域名解析商(服务商)，而指定的域名解析商(服务商)把对应的请求指令转发到对应的解析网络负载中，通过网络负载再转到服务器中，解析服务器里安装的nginx、apache、tomcat接到指令就立即创建资源句柄成功后将执行转发到nginx+php执行服务器中，nginx+php执行服务开始去执行，需要读取缓存的情况下，就去Redis中，需要读取MySQL数据的情况下，就去MySQL中，等业务操作完毕后返回结果给nginx，nginx接收到结果之后释放资源句柄并原路返回
2.2.6、特殊情况：oss文件存储服务器，我正常的操作方法是内网写入，外网读取；而MySQL集群是通过容器自身去做数据持平动作的；
2.3、服务架构
2.3.1、什么叫服务架构：就是通过父网络负载分发到指定的子网络负载中，最后通过所有的子网络负载再分发到对应的执行服务服务器上 (有轮询、权重等方式)，程序根据对应的配置去操作对应数据库容器集群，容器集群再操作数据库
**2.3.2、**什么叫服务：服务的统称被称作可执行、可翻译、可存储等成熟基于操作系统而运行的程序软件
2.3.3、nginx代理服务：专门做指派工作的
2.3.4、php执行服务：真正做事情的。如果需要读取MySQL数据库中的数据，他就会去MySQL容器中读取，而容器会到MySQL中操作，如果需要读取Redis缓存服务中的数据，他就会去Redis中读取，如果需要将文件上传到oss服务器中，他也是可以操作的，并返回结果
2.3.5、架构执行流程：用户通过手机或是台式机的app或是浏览器直接打开或是访问，前端程序根据当前页面的请求接口发送指令到指定的域名解析商(服务商)，而指定的域名解析商(服务商)把对应的请求指令转发到对应的解析网络父负载中，父网络负载会通过规则转发到指定的子网络负载中，然后通过子网络负载再转到服务器中，解析服务器里安装的nginx、apache、tomcat接到指令就立即创建资源句柄成功后将执行转发到nginx+php执行服务器中，nginx+php执行服务开始去执行，需要读取缓存的情况下，就去Redis中，需要读取MySQL数据的情况下，就去MySQL中，等业务操作完毕后返回结果给nginx，nginx接收到结果之后释放资源句柄并原路返回。
2.3.6、特殊情况：oss文件存储服务器，我正常的操作方法是内网写入，外网读取；而MySQL集群是通过容器自身去做数据持平动作的；
2.4、微服务架构
2.4.1、什么叫微服务架构:是一种将大型应用分解成多个较小的独立部分的架构模式，其中每个部分都有各自的责任领域，这些小的服务单元可以独立部署、扩展和维护，它们之间通过轻量级的通信机制互相沟通，通常是基于HTTP的RESTful API
2.4.2、什么叫服务：服务的统称被称作可执行、可翻译、可存储等成熟基于操作系统而运行的程序软件
2.4.3、nginx代理服务：专门做指派工作的
2.4.4、php执行服务：真正做事情的。如果需要读取MySQL数据库中的数据，他就会去MySQL容器中读取，而容器会到MySQL中操作，如果需要读取Redis缓存服务中的数据，他就会去Redis中读取，如果需要将文件上传到oss服务器中，他也是可以操作的，并返回结果
2.4.5、架构执行流程：用户通过手机app或是台式机的浏览器打开对应的系统后，根据当前页面里面的接口去对应地址拿去数据，而服务器接到总指令之后，他会根据不同规则匹配不同子网，子网会根据服务发现去对应的服务器，服务器将指令转发到对应的服务上，处理好之后，原路返回。而服务容器与服务容器之间采用容器通信方式，但是大多数还是采用服务监控、告警、熔断限流、日志等方式，但是也有采用异步方式，常用的是rocketmq
2.4.6、特殊情况：oss文件存储服务器，我正常的操作方法是内网写入，外网读取；而MySQL集群是通过容器自身去做数据持平动作的；
五、总结
在现实中，如果从0到1的项目，我会从公司运营资金有限的情况下，基本上技术的架构是由以上四种分段式完成的，如果公司的运营资金很充足的情况下，直接从集群架构走向分布式架构或是走向微服务架构。
在现实中，我会根据业务运行方向定义系统的架构过程。如果非SaaS系统的情况下，一般是由单机架构、集群架构、分布式架构来实现，如果做SaaS系统的情况下，一般是由单机架构、集群架构、微服务架构来实现。直到现在，我没有用过服务架构，不管是哪种思想。
这样选择的原因出于以下几个方面：
1、节约了技术部门人力成本及管理成本
由一个能力强的技术搭建好应用框架后组织开发，基本上不用过多技术会议。只要这个能力强的技术心态稍稍好点，压根不需要管理；
2、节约了运维成本
安装简单、方便，在不忙的时候，可以接入运维开发。为运营提供必要的辅助。
3、将服务器资源利用到极致
带宽方面：像现在的云服务器基本上1M带宽要72元，只有正规的IDC机房带宽稍稍便宜点，但是很多IDC机房的单个带宽也就100M。向这种情况，接收请求指令及加入队列后快速结束请求及释放连接数。
处理器、内存和存储容量方面：优化操作系统最大连接数及启动多个进程或是线程来同时处理请求。
4、从系统安全角度来说
因分布式采用的是业务拆分且可以细分为最小力度，这样就可以针对不同的业务api规划安全入网凭证、走不同的出网路线。
5、从我个人管理部门的角度来说
首先员工能留在你这里打工的无疑就分两种情况：
第一种就是能挣到钱，他凭能力吃饭。怎么能证明他的技术能力，就是靠合理的技术方案及技术实现过程来证明他的能力，而不是一味的增加服务器。
第二种就是能学到东西，而分布式架构思想本身就靠拆解来分解请求指令。换句话说就是，只要你语言服务能够及时处理指令，我就能源源不断的提供请求指令。