2018第47周日

Posted doit8791

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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的业务,因而累积了大量的用户数据,公司的运营需要通过这部分数据进行大数据分析和数字化运营,因而在这些企业里面往往还需要关注数据架构。

从事互联网应用的企业,往往首先关注的是应用架构,是否能够满足终端客户的需求,带给客户良好的用户体验,业务量往往会在短期内出现爆炸式的增长,因而关注高并发应用架构,并希望这个架构可以快速迭代,从而抢占风口。

 

以上是关于2018第47周日的主要内容,如果未能解决你的问题,请参考以下文章

2018第40周日

2018第43周日

2018第49周日

2018第38周日

2018第44周日

2018第35周日