用微服务的思想做ToB的SaaS，你没开始其实就已经错了

在大型系统或者大数据系统处理中，微服务模式是有一定的优势的，因为微服务的模式本质上就是对要处理的数据进行纵向划分，也就是按功能模块（按服务）划分，需要注意的是，每个微服务背后的数据库应该是独立存储的，也可以异构，这个可以根据自己的需要来进行选择。

但做SaaS系统，一般都是多用租赁模式，对于分割的基本需求就是按”用户“来分割，这种分割是横向的，这和微服务的思想是违背的。多用户租赁，以用户为视角是第一视角，很多操作都会发生在这个视角上。比如”用户“迁移。如果是微服务模式，一个用户数据的迁移会非常复杂，每个微服务都需要响应。如何保证在微服务模式的复杂调用关系下实现”用户“的整体迁移本身就是个非常复杂和困难的事情。

微服务模式虽然对功能的扩展有一定的支持，但如果功能涉及到的服务比较多，其扩展能力就会大打折扣。微服务的关联扩展能力是随着服务数的增多极速下降的。

用微服务开发SaaS对于运维来说其实市场噩梦，如果服务过多，而对于ToB的应用服务之间的调用关系又比较复杂，加上负载均衡的需要，每个服务可能有很多的运行实例，一个业务发生改变可能会导致其它服务都要改，就会使得发布和更新变得非常复杂。

因此，用微服务的思想做SaaS本质就是整体和局部的关系倒转，是不适合的。

当然，做SaaS系统不应该局限于一种架构，而应该是一种综合的或者多种架构的融合。另外就是我所主张的，SaaS服务必须和业务适应。即：面向应用架构。

这篇文章是我转发的，我觉得写的比较实在，大家可以看看：https://mp.csdn.net/console/editor/html/105549663