Eureka 的逻辑架构很清楚的表达了 Eureka Client、Server 之间的关系，以及他们的 Remote Call 是调用的。
Eureka 的限制随着容器的流行被逐渐的放大，我们渐渐的发现 Eureka 在很多场景下并不能满足我们的需求。
与 Eureka 不同，Consul 通过 Raft 协议提供了强一致性，支持各种类型的 health check，而且这些 health check 也是分布式的，也不需要使用大量的 SDK 来在代码中集成这些功能。
缺点也很明显，每个服务都有这一层代理，而且如果你的平台不提供这样的能力的话，自己手动去部署与管理高可用的 proxy 组件，成本是巨大的。
在微服务刚刚开始流行的时候，很多企业在探索的过程中开始使用 ZooKeeper 进行服务发现的实现，一方面是 ZooKeeper 的可靠、简单、天然分布式的优势可以说是直接的选择，
我们将调用方式分为“同步”与“异步”两种情况，在异步调用时，使用 MQ 传输事件，或者使用 Kafka 进行 Pub / Sub，事实上，Event Driven 的系统更有灵活性，也符合 Domain 的封闭。
在进行需求描述时，我们可以从多个角度来审视需求是否合理地表达出来：
满足需求，能带来什么价值，符合什么利益诉求？
需求无法满足时，会带来什么危害，有何潜在风险？
业务建模：是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系，业务建模强调以体系的方式来理解、设计和构架企业信息系统。
用例：每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，
对于软件开发的场景来说，把这些知识显式化，能快速对齐不同角色、不同参与方之间的概念，加速沟通，避免误解。
