在这种需求下，我们也希望服务之间的调用能够简单，最好能像方法调用一样简单。
对于 Netflix 来说，这样的模型是非常合理的，首先服务与 node 的关系相对静态，一旦一个服务投入使用其使用的虚拟机（我记得大多是 AWS EC2）也确定下来，
对于 Netflix 来说，这样的模型是非常合理的，首先服务与 node 的关系相对静态，一旦一个服务投入使用其使用的虚拟机（我记得大多是 AWS EC2）也确定下来，
Service mesh 作为实现微服务架构的新模式，核心思想在于进程之外 out-of-process 的实现功能，也就是 sidecar，
相对于 Consul 自己发明轮子的做法，Nacos 在协议的支持更全面，包括 Dubbo 与 gRPC，这对于广泛使用 Dubbo 的国内企业是一个巨大的优势。
相对于 kubernetes serivce, virtual service 可控制的地方更多，比如通过 destination rule 可控制下游，也可以实现根据路径匹配选择下游服务，也可以加入权重，重试策略等等。
一致性显然更重要。其实实现一个自己的服务发现并没有大多数人想的那么难，如果有一个 KV Store 去存储服务的状态，
每个软件需求是否都有唯一的标识符？
每个软件需求都可以验证吗？（如果可能，是否可正规化，量化）
是否对每个软件要求进行了优先排序？
但是架构不是平白无故就产生的，前文我们用登陆火星的案例也大概描述了系统的建设过程，那么在推导出架构之前，把用户不那么清晰的诉求转化成严谨的业务概念模型就很有必要了。
用例驱动的结果是我们的软件是以实现一个个场景为目的的，认为当一个系统的行为满足了所有涉众的期望之后，即满足了涉众使用系统的场景之后，该系统就是一个成功的系统。
