2018第47周日

 

目前用的较多的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 Cloud、Docker和Kubernetes的组合，能够构建更加完整和强大的微服务架构程序。经过三者的整合，使用Spring Boot提供应用的打包，Docker和Kubernetes提供应用的部署和调度。Spring Cloud经过Hystrix线程池提供应用内的隔离，而Kubernetes经过资源、进程和命名空间来提供隔离。Spring Cloud为每一个微服务提供健康终端，而Kubernetes执行健康检查，且把流量导到健康服务。Spring Cloud外部化配置并更新它们，而Kubernetes分发配置到每一个微服务。

基于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的业务，于是累积了大量的用户数据，公司的运营须要经过这部分数据进行大数据分析和数字化运营，于是在这些企业里面每每还须要关注数据架构。 从事互联网应用的企业，每每首先关注的是应用架构，是否可以知足终端客户的需求，带给客户良好的用户体验，业务量每每会在短时间内出现爆炸式的增加，于是关注高并发应用架构，并但愿这个架构能够快速迭代，从而抢占风口。