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

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

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

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

无状态组件:

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

微服务必经之路,企业应用架构蓝图,有状态和无状态组件之分_第1张图片

                                         图1,无状态组件

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

有状态的组件:

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

微服务必经之路,企业应用架构蓝图,有状态和无状态组件之分_第2张图片

                                               图2 有状态组件

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

   

微服务必经之路,企业应用架构蓝图,有状态和无状态组件之分_第3张图片

                                    图3,逻辑错误,无法完成a,b求和。

 

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

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

微服务必经之路,企业应用架构蓝图,有状态和无状态组件之分_第4张图片

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

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

版本

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

你可能感兴趣的:(istio,hibernate,微服务,架构,java)