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

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

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

无状态组件：

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

图1，无状态组件

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

有状态的组件：

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

图2有状态组件

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

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

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

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

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

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

版本

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