分布式架构的演进过程 _分布式架构

一个软件系统随着功能越来越多，调用量急剧增长，整个系统逐渐碎片化，越来越无序，最
终无法维护和扩展，所以系统在一段时间的野蛮生长后，也需要及时干预，避免越来越无序。架构的本质就是对系统进行有序化重构，使系统不断进化
那架构是如何实现无序到有序的呢？基本的手段就是分和合，先把系统打散，然后重新组合。分的过程是把系统拆分为各个子系统 / 模块 / 组件，拆的时候，首先要解决每个组件的定位问题，然后才能划分彼此的边界，实现合理的拆分。合就是根据最终要求，把各个分离的组件有机整合在一起，相对来说，第一步的拆分更难。
拆分的结果使开发人员能够做到业务聚焦、技能聚焦，实现开发敏捷，合的结果是系统变得柔性，可以因需而变，实现业务敏捷
架构的分类
架构一般可分业务架构、应用架构、技术架构
1. 业务架构从概念层面帮助开发人员更好的理解系统，比如业务流程、业务模块、输入输出、业务域
2. 应用架构从逻辑层面帮助开发落地系统，如数据交互关系、应用形式、交互方式，是的整
个系统逻辑上更容易理解，步入大家熟知的 SOA 就属于应用架构的范畴
3. 技术架构主要解决技术平台选型、如操作系统、中间件、设备、多机房、水平扩展、高可用等问题
需要注意的是，系统或者架构首先都是为人服务的，系统的有序度高，用用逻辑合理，业务概念清晰是第一位。现在大家讨论更多的是技术架构，如高并发设计，分布式事务处理等，只是因为这个不需要业务上下文背景，比较好相互沟通。具体架构设计时，首先要关注业务架构和应用架构，这个架构新手要特别注意。也是面试时候的痛点！
大型网站的架构演进
ps : 以下内容部分图片参考自《大型网站系统与 JAVA 中间件实战.pdf》
从一个电商网站开始
为了更好的理解，我们用电商网站来举例，作为一个交易类型的网站，一定会具备
用户（用户注册、用户管理）、商品（商品展示、商品管理）、交易（下单、支付）这些功能假如我们只需要支持这几个基本功能，那么我们最开始的架构应该可能是这样的

文章插图

这个地方要注意的是，各个功能模块之间是通过 JVM 内部的方法调用来进行交互的，而应用和数据库之间是通过 JDBC 进行访问。
单机负载告警，数据库与应用分离
随着网站的开放，访问量不断增大，那么这个时候服务器的负载势必会持续升高，必须要才需一些办法来应付。这里先不考虑更换机器和各种软件层面的优化，先从架构的结构上来做一些调整。我们可以把数据库与应用从一台机器分到两台机器

文章插图
【分布式架构的演进过程】
变化：
网站从一台变成了 2 台，这个变化对我们来说影响非常小。单机的情况下，我们应用采用 JDBC 的方式来和数据库进行连接，现在数据库与应用分开了，我们只需要在配置文件中把数据库的地址从本机改成数据库服务器的 ip 地址就行。
对于开发、测试、部署都没有影响调整以后我们能够缓解当前的系统压力，不过随着时间的退役，访问量继续增大的话，我们的系统还是需要做改造
为什么这么分呢？从计算机本身的角度来考虑的话，一个请求的访问到处理最终到返回，性
能瓶颈只会是：CPU、文件 IO、网络 IO、内存、等因素。而一台计算机中这些纬度是有性
能瓶颈的，如果某个资源消耗过多，通常会造成系统的响应速度较慢，所以增加一台机器，
使得数据库的 IO 和 CPU 资源独占一台机器从而增加性能。
这个地方插入一点题外话，就是简单说一下各个资源的消耗原因。
CPU/IO/内存：
1. 主要是上下文的切换，因为每个 CPU 核心在同一时刻只能执行一个线程，而 CPU 的调
度有几种方式，比如抢占式和轮询等，以抢占式为例，每个线程会分配一定的执行时间，
当达到执行时间、线程中有 IO 阻塞或者有高优先级的线程要执行时。CPU 会切换执行其
他线程。而在切换的过程中，需要存储当前线程的执行状态并恢复要执行的线程状态，这
个过程就是上下文切换。比如 IO、锁等待等场景下也会触发上下文切换，当上下文切换