Category: 微服务

我们在前文中介绍了DDD在微服务boundary划分中的指导意义，但显然它并不是唯一的划分准则，本文就来介绍几个其它在微服务划分的时候经常需要的考虑因素，我们通常会把它们和DDD集合起来做最终的决定。 波动性（Volatility） 这个世界变化很快，我们有时需要提前考虑系统某一个部分是否会频繁修改，以及是否需要把相应的功能抽象出来成为服务，从而使他们的执行更有效。 一个简单的例子，早期的购物网站可能不支持线上支付，那么在支付页面只需要留一个订购电话，用户只能拨打电话进行订购。这个时候的支付功能是否需要独立一个service来处理呢？也许不一定。而随着时间的推移，支付的方式不断进行演进，比如开始支持信用卡的支付，支持微信支付宝的支付，这个时候把支付独立出来成为一个新的微服务是否更加合理？假设后来每种支付方式开始出现不同的后续操作，比如微信支付之后有了微信购物抢红包的功能，或者使用支付宝支付有了其特有的couple和额外操作等等，是否需要把微信，支付宝都进行独立微服务处理呢？这些都是需要考虑的，总得来说，考虑服务的波动性也就是改变频率是一个不错的建议。 数据...

每天产生的数据正在呈现指数级的增长，不管这些数据是由各种传感器产生还是有用户点击网络产生，亦或是系统内容交互的数据，我们的应用需要处理和这些数据相关的事件将会越来越多。那么怎样设计一个很好的架构来处理这些事件呢？ 本文，我们将会讨论什么是事件驱动的架构（EDA）以及这个架构是这样把事件放到系统的核心地位的。然后我们再聊聊这样的架构都有哪些优势。 什么是事件 所谓的事件，就是记录已经发生的事情，或者一个状态的改变。他们是不可改变的，并且是按照发生的顺序排列的。对这些事件感兴趣的部分可以注册这个事件，然后再根据这些事件来做相应的商业逻辑。 什么是事件驱动的架构...