Eureka 的限制随着容器的流行被逐渐的放大，我们渐渐的发现 Eureka 在很多场景下并不能满足我们的需求。
首先对于弱一致性的需求使得我们在进行弹性伸缩，或者蓝绿发布时就会出现一定的错误，
实际上，我们刚才提到的“服务发现”是“客户端的服务发现（client-side service discovery）”，假设订单系统运行在四个节点上，每个节点有不同的 IP 地址
只要进行一些配置就好。但是这也不是免费的，随着服务数量的上升，手动的管理这么多的 proxy 与 sidecar，没有自动化的报警和响应手段，都会造成效率的下降。
进行技术选型的压力是非常之大的，随着技术的演进、人员的更替，很多系统逐渐变成了无法修改、无法移动的存在，作为技术负责人我们在进行这件工作时应该更加注意，
选择某项技术时也需要考虑自己能否负担的起。Spring Cloud 提供的微服务方案在易用性上肯定好于自己在 Kubernetes 上发明新的，
是否明确指出了软件需求之间的重叠交叉？
是否明确规定了初始系统状态？
软件需求是否表达了逻辑模型， 而不是实现形式？
软件需求是否以结构化的方式表示为抽象层次？
是否足够清楚，逻辑模型的结构
软件要求是否已正式形式化？
概念模型：是用一组概念来描述一个系统，或用任何代替的形式来描述一个概念，以期能进一步了解或说明事物的运作原理。
场景：参与者和系统之间的一系列特定的活动和交互；
用例：一组相关的成功和失败的场景集合，用来描述参与者如何使用系统来实现目标。
