多研究些架构，少谈些框架（2）-- 微服务和充血模型 about joecao.github.io HOT 16 OPEN

充血模型不等于一定要把状态加载到内存中去操作，重点在于把业务规则封装到对象中
非要加载到内存中去操作，是人为制造问题然后又来提解决方案
做DDD/MSA应该保持无状态，整体架构是很简单清晰的

from joecao.github.io.

一家之言: 面向对象这个**也许是一个错误的**.... 微服务 抛开面向对象**, 面向数据

from joecao.github.io.

@XingZheFeng 你的担忧很有道理，我在文章里面也说了，这个世界是纯数学构建的，有一天我们可以用公式来精确的计算任何一个逻辑。就像围棋，我们把每个变化都算清楚就是围棋之神了， 但是现在我们还做不到，只能通过剪枝和蒙特卡洛加上深度学习去寻求近似解。 而面向对象、DDD本身是经验性的，不能严格证明。但是他是我看到的目前最接近业务逻辑近似解的方案了。

from joecao.github.io.

文章写的不错，求私聊

from joecao.github.io.

我是电子工业出版社博文视点策划编辑，微信yingzidd

from joecao.github.io.

@yingzidd12 本文采用 CC BY 3.0 CN协议 进行许可。 可自由转载、引用，但需署名作者且注明文章出处。 有什么问题可以邮件联系我。

from joecao.github.io.

划分业务的同时，也将存储模型根据业务划分，与业务逻辑构成一个 Bound Context，引入一个问题，这样的微服务是否具有良好的水平扩展性。
毕竟微服务发展的一个驱动力是面对突发流量时的，快速反应能力。当一个微服务成为瓶颈的时候，我可以利用容器技术创建多个相同微服务。那么当存储与业务逻辑绑定的时候，这种水平扩展是如何实现。

from joecao.github.io.

@magichan 实际上除非是图形处理这种消耗CPU的业务，我们90%以上的业务的性能瓶颈都在IO上，也就是存储上。这种情况下，你用容器创建更多的业务逻辑的微服务进程也是徒劳，并不能解决性能问题。但是如果BC和存储在一起，你反而可以有针对性的发现有性能瓶颈的BC，然后采用分区分片的方式，或者直接用NoSQL去存储热点的数据。不需要所有的数据库都跟着一起变化，充分发挥微服务独立松耦合的特性，去解决水平扩展。

from joecao.github.io.

赞，已关注已star

from joecao.github.io.

很好的文章。我觉得“充血”模型这种说法是不合适的，模型本来就应该有合适的行为，贫不好，充也不好。

from joecao.github.io.

看到文中提到的“充血”例子，不可以通过Application中通过加数据库事务实现？忘指教，已经开发了N年的贫血了。

from joecao.github.io.

@hc24 充血模型已经把状态加载到内存中了，修改都是在自己的内存里面，再写到数据库的时候，必然会有并发的问题。这个缺陷也是充血模型必须付出的代价，任何技术都是有代价的。所以一般简单的基础业务，没有必要使用充血模型。

from joecao.github.io.

【虽然我们用Java这样的面向对象语言来开发，但是其实和过程型语言是一样的，所以很多情况下大家用数据库的存储过程来替代Java写逻辑反而效果会更好】
个人拙见：互联网企业其实是比较忌讳使用存储过程来处理业务，因为大多数高并发场景都是为了解决数据库的负担，使用存储过程有些适得其反。

from joecao.github.io.

@thefloe 貌似值对象 集合的话 会全部加载进来吧

from joecao.github.io.

贫血模型还有个很大的问题是可测试性太差

from joecao.github.io.

充血模型不等于一定要把状态加载到内存中去操作，重点在于把业务规则封装到对象中
非要加载到内存中去操作，是人为制造问题然后又来提解决方案
做DDD/MSA应该保持无状态，整体架构是很简单清晰的

同意，在于行为抽象，具体持久化和防并发完全可以依靠于db。

from joecao.github.io.