多层API构架中隔绝状况
除了分拆微服务项目构架的统计数据传输商业模式(比如，分拆为该事件)以外，还有一种赢得连续性的方式是分拆每一微服务项目的内部连续性。相比较于期许透过统计数据传输赢得连续性，比不上期许查阅时统计数据的连续性。
一般来说，这是透过隔绝状况来同时实现的，换言之，“每一微服务项目都包涵它自己的状况”。在这种隔绝状况商业模式中，每一微服务项目都包涵两个内部统计数据储存，它不断地与内部储存（不论是该事件笔记还是企业资产）进行协同，使内部储存成为“单个真实世界源”。事实上，这可能是很十分困难的，即使单个真实世界源的商业模式常常反映了主统计数据处理的复杂程度及其相关考验。
相比之下，使用内部储存作为微服务项目的单个真实世界源要实际得多，即使取值微服务项目一般来说具有单个商业用途的优点。比如，隔绝顾客的状况很十分困难，但隔绝顾客邮箱门牌号的状况并不十分困难。因此，隔绝状况商业模式必须支持非常mammalian的微服务项目才能成功。因此，隔绝状况商业模式常常还需要触发器该事件散播，将状况更动从两个点传达到另个一点。隔绝状况商业模式也能看做是这种“分布式资料库”，对于传统的RDBMS结构设计来说，每一微服务项目几乎都代表者两列统计数据。
微服务项目包涵两个统计数据储存，它是微服务项目所代表者的虚拟的真实世界源。比如，“商品”微服务项目能包涵两个MySQL资料库，该资料库包涵相关商品的大部份重要信息，因此是查阅或预览“商品”基本概念的惟一方式。
与吻合于SOA的商业模式相同，宠信性在隔绝状况商业模式结构设计中并并非优先选择考虑的难题。当然，该商业模式中每一微服务项目都有两个“商业用途”，并时常在相同的情景中被出访。但每一微服务项目的结构设计并没有考虑到宠信性。如果发生了宠信，那将是碰巧的，而并非SOA体系结构内含的企图。
难题：
当存在数个真实世界源时，极难同时实现统计TPM。
软件系统：
为每一取值的业务虚拟选定两个代表者单个真实世界源的微服务项目，并将状况PCB在微服务项目中。
应用领域：
微服务项目包涵两个统计数据储存，它是微服务项目所代表者的虚拟的真实世界源。比如，“商品”微服务项目能包涵两个MySQL资料库，该资料库包涵相关商品的大部份重要信息，因此是查阅或预览“商品”基本概念的惟一方式。
影响：
1.为了确保状况统计数据不被复制或其他方式出访，隔绝状况商业模式需要这种治理。
2.在处理现有资产（如ERP）时，必须使用“扼杀”商业模式，用新的微服务项目构架逐个替换现有系统的统计数据储存。
3.隔绝状况商业模式回避了统计数据同步的难题，所以如果统计数据虚拟相同步，就无法轻松回退。
目标：
1.内聚性：由于其标准化的优点，隔绝状况商业模式的构架非常容易使用和理解。
2.可伸缩性：隔绝状况模式的构架具有很强的可伸缩性（每一小组件都能同时实现自己的伸缩模型）。
3.更动速度：由于构架的强内聚性，隔绝状况商业模式具有快速的更动速度，但需要治理来确保该构架不会被破坏。
主要特点：
1.触发器通信机制将带来高效的IPC（Inter-Process Communication，进程间通信）。
2.这种商业模式的结构设计非常灵活，所以具有快速的更动速度。
3.这种商业模式只有单个的真实世界源，所以统计数据连续性很好。
4.可伸缩性可能会带来考验，即使同时需要扩展统计数据储存。
5.在规模上，极难将统计数据模型划分为完全独立的模块。在某些阶段，视图之间的连续性变得非常重要。
隔绝状况商业模式如何与现有系统、SOA或API共存？
无法共存。如果您构建式。
隔绝状况商业模式一般来说与“扼杀”商业模式很好地结合在一起，在“扼杀”商业模式中，您试图减少对取值企业应用领域程序或其他系统的使用，即使这些应用领域程序或系统没有给您足够的时间来评估所需的价值。随着时间的推移，您将用这些隔绝的微服务项目替换原始系统中的功能，并停用原始系统中的那些特定功能。
换言之，这并非集成商业模式。这里的目标是使用微服务项目创建两个新的、快速移动的部分同时实现，这将使您赢得现有系统无法提供的速度和规模优势。
如您对
未经同意，本文禁止转载或摘编。
