Spring Cloud Alibaba专题--2.2.5.RELEASE--服务层的架构演进（二）

旧城等待， 2023-01-14 05:54 109阅读 0赞

### 数据层的扩展 ###

之前聊过关于数据层的可扩展架构，使用的核心组件就是Sharding Sphere。事实上整个数据层的架构演变是基于业务数据驱动的，当业务数据量及访问量逐渐增大，我们不得不演进数据层的架构使得数据层能够抗住更多的并发量以及获得更快的性能。在架构演进的过程中，随着垂直横向拆分，读写分离的加入，数据层在获得了更强的性能及扩展能力，但这一切并非是0成本的，在获得了更强的能力的同时，随着架构的演进，分布式事务问题，分布式主键问题等等都是需要去处理热点问题，如果对数据层的扩展感兴趣可以移步[ShardingSphere应用专题–4.1.1版本–章节导航（一）][ShardingSphere_4.1.1]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNDU3NjY1_size_16_color_FFFFFF_t_70]

### 服务层架构演进 ###

#### 1.单体服务 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNDU3NjY1_size_16_color_FFFFFF_t_70 1]

*  单体服务架构的好处：  
    开发简单，模块本地调用，调用过程简单，一个字快。。。
 *  单体服务架构的局限：  
    1.单点不可用问题  
    2.项目臃肿，编译打包都很慢，打出来的包动辄几百兆，项目部署回滚等操作会是噩梦  
    3.性能瓶颈很明显，冷门模块和热门模块争抢服务器资源  
    4.有的模块是CPU密集型，有的可能是IO密集型，模块性能偏好不同，这个架构整个一锅炖。。

#### 2.集群服务架构 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNDU3NjY1_size_16_color_FFFFFF_t_70 2]

*  架构的好处：  
    通过部署多个应用服务器，通过反向代理暴露服务集群，很好的解决了单点问题。
 *  架构的局限：  
    1.项目臃肿，服务资源分配不合理，模块性能偏好一锅炖的问题仍然没有解决
 *  新引入的问题：  
    1.多个服务，服务本身是无状态的，那么必须通过外部服务或存储保持用户的登录态  
    2.多应用间同时执行逻辑，系统自带的锁机制（如java的同步锁，ReentrantLock等）已经无法在多应用之间处理并发问题了，必须引入分布式锁

补充：一般开发的应用，为了后期服务化，都会在单体应用阶段就解决以上的登录态问题和分布式锁问题，这样单体服务架构升级到集群架构只需要扩展机器即可。否则这部分的历史债务偿还将会很恶心。。。

#### 3.微服务架构 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNDU3NjY1_size_16_color_FFFFFF_t_70 3]

*  架构的好处：  
    解决了上面说的所有问题
 *  新引入的问题：  
    1.某个功能按照业务被拆分到一个或多个服务器，多服务之间的感知必须依赖服务发现相关的中间件。服务的动态注册以及失活下线等功能直接影响整服务的业务调用。  
    2.服务间需要通过RPC调用，单个服务模块的多个机器需要负载均衡，整个链路调用变的异常复杂，链路追踪以及系统监控也会成为难题  
    3.大量的中间件的引用，中间件的高可用性将直接影响整个系统的可用性  
    4.单模块集群虽然可以靠着扩展来提高应用的高可用，但是单模块依赖RPC调用，还是存在一定概率出现高延迟甚至宕机的可能。这个时候就有可能因为链路的某个模块高延迟或宕机，导致整个调用链路延迟陡增甚至夯住，大批的资源被线程占用并挂起，进而引起其他模块甚至整个系统集群雪崩  
    5.大量的中间件的引用以及其他第三方方案的使用，并非只是单纯的1+1，多个中间件还存在交互，比如注册中心和负载均衡模块。这就使得搭建这种应用的门槛水涨船高。

补充：在微服务架构没有被广泛应用之前，SOA架构一直是企业津津乐道的架构，由于SOA架构和微服务架构之间很像，而且现实中，只要大家想上分布式，一般都是直接使用微服务架构，因为SOA和微服务之间虽然存在很多的相似性，但并不满足线性扩展，微服务架构的思想比SOA架构更加成熟。所以这里直接就略过了，感兴趣的可以自行了解

### 架构扩展的理论–AKF扩展立方体 ###

AKF扩展立方体（Scalability Cube），是《架构即未来》一书中提出的可扩展模型，这个立方体有三个轴线，每个轴线描述扩展性的一个维度，他们分别是产品、流程和团队：

X轴 —— 代表无差别的克隆服务和数据，工作可以很均匀的分散在不同的服务实例上；

Y轴 —— 关注应用中职责的划分，比如数据类型，交易执行类型的划分；

Z轴 —— 关注服务和数据的优先级划分，如分地域划分。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNDU3NjY1_size_16_color_FFFFFF_t_70 4]  
这个理论阐述了分布式系统的扩展理论模型  
可以看到，无论是数据层的扩展还是服务层的扩展，在ACK理论模型中得到了高度的统一。

[ShardingSphere_4.1.1]: https://blog.csdn.net/qq_31457665/article/details/114970005
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNDU3NjY1_size_16_color_FFFFFF_t_70]: /images/20221022/ab86419b89c5443c9ea5b24a272445f5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNDU3NjY1_size_16_color_FFFFFF_t_70 1]: /images/20221022/c7bb1bcd16754741b64495f76dcb4fcc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNDU3NjY1_size_16_color_FFFFFF_t_70 2]: /images/20221022/e027707165df4b8bbedd92f69ff01556.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNDU3NjY1_size_16_color_FFFFFF_t_70 3]: /images/20221022/aaa3f3e13ebc42a7bc963997299ad545.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMxNDU3NjY1_size_16_color_FFFFFF_t_70 4]: /images/20221022/cea8b964fbbd4ce3a9d64274f906fa46.png