必定要记住！微服务架构的罕用设计形式！

用Scale Cube方法设计运行架构，将运行服务按性能拆分红一组相互单干的服务。每个服务担任一组特定、关系的性能。每个服务可以有自己独立的数据库，从而保障与其余服务解耦。

1、聚合器微服务设计形式

​ 聚合器调用多个服务虚现运行程序所需的性能。它可以是一个便捷的Web页面，将检索到的数据启动处置展现。它也可以是一个更上档次的组合微服务，对检索到的数据参与业务逻辑后进一步颁布成一个新的微服务，这合乎DRY准则。另外，每个服务都有自己的缓存和数据库。假设聚合器是一个组合服务，那么它也有自己的缓存和数据库。聚合器可以沿X轴和Z轴独立裁减。

2、代理微服务设计形式

这是聚合器形式的一个变种，在这种状况下，客户端并不聚合数据，但会依据业务需求的差异调用不同的微服务。代理可以仅仅委派恳求，也可以启动数据转换上班。

3、链式微服务设计形式

​ 这种形式在接纳到恳求后会发生一个经过兼并的照应，在这种状况下，服务A接纳到恳求后会与服务B启动通讯，相似地，服务B会同服务C启动通讯。一切服务都经常使用同步信息传递。在整个链式调用成功之前，客户端会不时阻塞。因此，服务调用链不宜过长，免得客户端常年间期待。

4、分支微服务设计形式

这种形式是聚合器形式的裁减，准许同时调用两个微服务链

5、数据共享微服务设计形式

自治是微服务的设计准则之一，就是说微服务是全栈式服务。但在重构现有的“单体运行（monolithic application）”时，SQL数据库反规范化或许会造成数据重复和不分歧。因此，在单体运行到微服务架构的过渡阶段，可以经常使用这种设计形式