1.微处事架构模式方案

用Scale Cube要领设计应用架构，将应用处事按成果拆分成一组彼此协作的处事。每个处事认真一组特定、相关的成果。每个处事可以有本身独立的数据库，从而担保与其他处事解耦。

1.1 聚合器微处事设计模式

聚合器挪用多个处事实现应用措施所需的成果。它可以是一个简朴的Web页面，将检索到的数据举办处理惩罚展示。它也可以是一个更高条理的组合微处事，对检索到的数据增加业务逻辑后进一步宣布成一个新的微处事，这切合DRY原则。别的，每个处事都有本身的缓存和数据库。假如聚合器是一个组合处事，那么它也有本身的缓存和数据库。聚合器可以沿X轴和Z轴独立扩展。

1.2 署理微处事设计模式

这是聚合器模式的一个变种，在这种环境下，客户端并不聚合数据，但会按照业务需求的不同挪用差异的微处事。署理可以仅仅委派请求，也可以举办数据转换事情。

1.3 链式微处事设计模式

这种模式在吸收到请求后会发生一个颠末归并的响应，在这种环境下，处事A吸收到请求后会与处事B举办通信，雷同地，处事B会同处事C举办通信。所有处事都利用同步动静通报。在整个链式挪用完成之前，客户端会一直阻塞。因此，处事挪用链不宜过长，以免客户端长时间期待。

1.4 分支微处事设计模式

这种模式是聚合器模式的扩展，答允同时挪用两个微处事链

1.5 数据共享微处事设计模式

自治是微处事的设计原则之一，就是说微处事是全栈式处事。但在重构现有的“单体应用（monolithic application）”时，SQL数据库反类型化大概会导致数据反复和纷歧致。因此，在单体应用到微处事架构的过渡阶段，可以利用这种设计模式

1.6 异步动静通报微处事设计模式

固然REST设计模式很是风行，但它是同步的，会造成阻塞。因此部门基于微处事的架构大概会选择利用动静行列取代REST请求/响应