多层API构架中的状况拷贝（该事件源）
其本质上，状况拷贝商业模式是用来化解状况隔绝商业模式造成的难题；简而言之，状况拷贝商业模式跟状况隔绝商业模式一样，也须要统计数据的连续性。举个简单的范例，假定有两个包涵产品目录、产品价格和汇率三个组件的微服务项目构架，假如该构架中的每两个组件都包涵各自该事件的隔绝状况，那产品目录、产品价格和汇率就会变得互相冲突。这也就意味着，构架中产品目录、产品价格和汇率的任何两个出现机械故障或者更动，单厢导致另两个功能的失败。
上面所讲的组件间互相冲突的难题是能透过拷贝状况来化解的；换言之，提供更多两个原则上的位置来储存大部份状况变动，每一分立的微服务项目都能依照这些变动来复建其内部状况。通常情况下，状况拷贝与该事件源的标识符并存，基于事件驱动的微服务项目仅透过两个不容变的该事件笔记进行通信——这提供更多了两个分立且单个的状况管理工具，统计数据完全一致但难以查阅，因而完成了该事件笔记的 “蔡荣快照”工作。
状况拷贝商业模式的结构设计，其本质上是为了同时实现最后连续性。虽然在传统的外交事务结构设计中，最后连续性似乎是两个难题，但是透过深入细致介绍结构设计的其本质是能改进这个难题的。比如，人们可能将认为商业银行帐户的贷记是所谓的买卖，但大多数现代商业银行已经意识到，与耗费心力保证每一大笔买卖都是一致的，还不如建立两个最后完全一致的贷记（假如帐户存有则贷记，然后保证造成资金不容用的可能将时的精确性）。这代表了对IT系统的一种捷伊思索方式，但它能增添更大的灵巧度和更动速率，从而加快价值同时实现的速率。
当然，状况拷贝商业模式具有一定的诱惑力。它须要对其管理的状况以及每一微服务项目的行为有深入细致的介绍，以期能预估。然而，状况拷贝商业模式也间接化解了在其他商业模式中造成的难题，因而，此种商业模式能看做是两个非常具体的取舍。这种商业模式能增添最后连续性（而不是间接的）、由上而下结构设计的收敛性和可预估的更动速率。
难题：
当存有多个状况管理工具时，很难同时实现统计数据的准确性。
化解方案：
对统计数据的大部份更动保持单个的管理工具，并依照须要拷贝统计数据。
应用：
1.将大部份的状况更动作为该事件发送至永久性该事件笔记。当须要查阅统计数据时，透过计算该事件笔记中的大部份更动来构筑蔡荣快照。
2.通常，该事件笔记的计算是透过沿着快照建立快照来简化的，这样就不须要每次都进行完整的重新计算。
影响：
1.状况拷贝商业模式具备强收敛性。
2.由于结构设计中所谓的命令-查阅请求分离原则，拷贝状况商业模式具有很强的可伸缩性。
3.状况拷贝商业模式很难可视化和理解其逻辑依赖性（物理依赖性已明显减少）。
目标：
1.收敛性：由于其标准化的特性，拷贝状况商业模式的构架非常容易使用和理解。
2.可伸缩性：具有很强的可伸缩性。
3.更动速率：非常快速。
主要特点：
1.异步通信机制将增添高效的IPC（Inter-Process Communication，进程间通信）。
2.此种商业模式的结构设计非常灵巧，所以具有非常快速的更动速率。
3.统计数据的连续性很好，但是有两个单个的真实源（通常是该事件笔记）。
4.很强的可伸缩性；此种商业模式的结构设计优先考虑分立扩展每一部件的能力。
5.自主性非常高，但同时增添了非常复杂的结构设计。
拷贝状况商业模式如何与现有系统、SOA或API并存？
与状况隔绝商业模式不同，状况拷贝商业模式只须要两个关键的更动，就能很好地与现有的IT系统并存：此种商业模式中的该事件笔记必须成为它所包涵的任何内容的唯一真实源。这意味着，只要现有的IT系统和API在更新该事件笔记的同时并从中更新，它们就能继续使用。
状况拷贝商业模式还能以一种“扼杀”的方式来使用：透过将该事件逐个迁移到此种商业模式，为服务项目获得更动速率和高伸缩能力。假如你愿意的话，这将用两个稳定的方式逐步替换现有的同时实现，并与现有的IT系统保持同步。
如您对本文分享的五种常见的微服务项目构架结构设计商业模式感兴趣，
未经同意，本文禁止转载或摘编。
