如何成功搞挂一个线上系统（四）？

然而，这些都不是死亡原因。

微服务的定义人云亦云，但是基本原则不会变：服务要自治。逻辑实现跨服务，数据高度耦合。这是致命的伤。

同时，应变不及时，同时业务量急剧增长，数据量急剧增长，从年初的1000万，半年迅速增长到3000万。

这段时间，独立的服务因为有独立的团队负责，所以可以应对自如。形象的说法是，可以在各个环节上微调。

死在哪里？

死在没有拆分成功后的主服务上。因为领域的划分不清，导致最终所有的更新都集中在订单上，导致实际上更新和新增订单的比例大约有12:1。同时，超级宽表导致单次更新很多（需要量化）……

可以跨过生存门槛的系统，都会经历多次的有效重构。没有跨过生存门槛的系统，都是因为历史的坑没有填平，又挖了新的坑。

如果要列举一下这一年来犯的错误，如下:

Vaddin拆解未完成...

前后端分离未完成...

API膨胀和治理失败...

核心领域边界不清...

服务化防御性能力不足...

数据解藕不及时...

心情不好...