微服务必经之路，企业应用架构蓝图，有状态和无状态组件之分

微服务如火如荼但很多时候是事倍功半花了大力气收获很少。怎样实现一键扩展负载量自然伸缩高可用呢 一般公司都有了企业级的应用我们通常所说的三层架构即用户界面或者说前台服务器层或者说后台然后是数据库或者说持久层。

我们现在说微服务有很多好处的确有很多好处高可用一个组件坏了马上生成备用组件能够横向扩展自动分担负载。当服务器空闲时又可以释放容量减少资源从而减少成本。微服务带来的好处还有很多不一一展开。

那么企业级的应用怎样向微服务迁移呢首先要理清业务逻辑中即企业应用中无状态组件和有状态组件的区分。 首先我们来看概念什么是无状态的组件什么是有状态的组件。

无状态组件

即前后请求无所谓类似功能模块的先后接受位置的。比如图1

                                         图1无状态组件

请求给组件1和组件2没有关系因为没有中间量或状态量的保存不存在请求到组件1还是组件2会有不一样的结果。可以自由横向扩展一般高可用采取N+1模式。后续看图4。

有状态的组件

有状态的组件就是先后来的请求有位置要求相关的请求如果以前的是由组件3接受后续相关的请求也要有相同组件3接受。请看图2

                                               图2 有状态组件

组件3是有状态的最典型的例子是电商平台上的购物车如果用户A的第一个订单是落在组件3里那么第二个订单也要落在组件3里不让无法求总和。一个错误的情形如图3. 

   

                                    图3逻辑错误无法完成ab求和。

 

为什么要区分开无状态组件和有状态组件很大原因是有状态组件的高可用是1+1来完成的而无状态组件是N+1来完成的。理论上说无状态组件的横向扩展很自由的可以无限制。

所以当我们区分开无状态组件和有状态组件通向微服务的道路就部分理顺了。我们来看通向微服务架构的必经之路企业级架构的蓝图就是图4.

                                          图4  企业级架构后台和持久层

Float IP 就是一个物理地址连接多个逻辑地址。当一个逻辑地址宕机另一个逻辑地址就填补上了。 

版本

2023年1月26日于上海第一版。