目前用的较多的Spring Could是注册中心consul，它通过集群设计、raft选举算法，gossip协议等机制确保consul服务的高可用，若有更高的容灾机制，则要异地多数据中心设计。
Spring Could Config中心也是一个重要的独立组件，所有的微服务应用都要调它获取配置信息。
Spring Could中微服务间调用负载均衡、服务熔断、限流等机制是都是在服务消费端实现，对消费端代码有一定的侵入性，这与Service Mesh的Proxy模式不同。
当然，Spring Could 组件也有不少不支持的功能：
Spring Could Config没有可视化管理后台，不支持复杂的权限和版本管理，配置修改后无法自动进行配置信息的推送。
Spring Could默认注册中心Erueka是AP型设计，强调高可用性，极端情况下可能出现多个注册中心节点不一致，甚至注册数据丢失情况。
Spring Could集成的网关Zuul负载均衡功能需要结合Ribbon实现，它用Servlet架构，基于JVM实现，高并发下性能会成为瓶颈。
Spring Could Hystrix无法实现对API网关各个具体服务接口分别捷星限流、降级、熔断的控制需求。
Spring Could Sleuth集成经典的ELK知识对日志级别做跟踪和监控，实际项目还需要APM的监控机制。
Spring Could微服务对代码有一定的入侵性，如果是老项目没办法升级用Spring boot框架开发的话，你可以考虑ServiceMesh。
基于Spring Could实现的微服有务技术门槛高，多语言支持不足，对业务代码有一定的侵入性，技术升级切换成本高的问题，于是有人开始尝试用Servie Mesh来解决。
微服务的概念在2014年3月由Martin Fowler首次提出，而Service Mesh的概念则是在2016年左右提出，Service Mesh至今也经历了第二代的发展。直到2017年年底，当非侵入式的Service Mesh技术终于从萌芽到走向了成熟，当Istio/Conduit横空出世，人们才惊觉：微服务并非只有侵入式一种玩法，更不是Spring Cloud的独角戏！
企业上的三大架构为IT架构，应用架构和数据架构，在不同的公司，不同的人，不同的角色，关注的重点不同。
对于大部分的企业来讲，上云的诉求是从IT部门发起的，发起人往往是运维部门，他们关注计算，网络，存储，试图通过云计算服务来减轻CAPEX和OPEX。
有的公司有ToC的业务，因而累积了大量的用户数据，公司的运营需要通过这部分数据进行大数据分析和数字化运营，因而在这些企业里面往往还需要关注数据架构。
从事互联网应用的企业，往往首先关注的是应用架构，是否能够满足终端客户的需求，带给客户良好的用户体验，业务量往往会在短期内出现爆炸式的增长，因而关注高并发应用架构，并希望这个架构可以快速迭代，从而抢占风口。
对于大部分的企业来讲，上云的诉求是从IT部门发起的，发起人往往是运维部门，他们关注计算，网络，存储，试图通过云计算服务来减轻CAPEX和OPEX。
有的公司有ToC的业务，因而累积了大量的用户数据，公司的运营需要通过这部分数据进行大数据分析和数字化运营，因而在这些企业里面往往还需要关注数据架构。
从事互联网应用的企业，往往首先关注的是应用架构，是否能够满足终端客户的需求，带给客户良好的用户体验，业务量往往会在短期内出现爆炸式的增长，因而关注高并发应用架构，并希望这个架构可以快速迭代，从而抢占风口。