精华内容
下载资源
问答
  • 企业微服务
    千次阅读
    2022-04-25 10:15:23

    背景

    随着业务需求的日渐复杂以及产品迭代节奏的不断加快,业务开发部门面临着前所未有的压力。为了抢占先机,用最快的速度准确把握用户需求的变化,优化开发出来的业务产品,微服务(MicroServices)架构技术在各大企业不断生根发芽。

    微服务架构可以极大的降低业务的复杂性。开发和部署相对大单体架构而言更加简单,单个微服务的功能可以更快地更改,启动和调试单个微服务的时间成本相比于单体应用也大大减少。普遍而言,微服务架构具备以下优点:

    • 将业务分而治之,降低业务复杂性,让业务易于理解、修改和维护
    • 模块化部署,修改代价小,迭代速度快,有很好的扩展性
    • 更好的容错性,业务服务各司其职,单点故障不易影响全局

    微服务架构
    然而微服务架构并非没有代价,就如软件工程中没有真正的银弹。

    原来在单体架构时,所有的逻辑都在一个服务内处理,方法和方法之间是进程内部的调度方式,然而采用微服务架构之后,服务与服务之间需要通过网络相互沟通,一个业务的实现往往是多个服务的共同作用下完成,由此带来了一系列的问题。

    企业微服务化面临的挑战

    复杂的网络通信提升了故障出现的概率

    在微服务架构体系中,服务与服务之间需要通过网络相互沟通,意味着研发人员在原本的业务逻辑之外,还需要额外考虑网络通信相关的问题。比如服务在向其上游服务发起请求时需要对上游服务的各种意外响应做出处理,常见的有401错误,404错误,500错误,503错误等。此外还涉及到对网络延迟,网络故障等环境问题做出处理。

    一旦研发人员不能妥善处理这些网络通信带来的意外情况,随着微服务数量的不断变多,故障的风险概率将会随之增大,进而影响系统的整体稳定性。

    海量的微服务加大了故障排查的难度

    随着业务的发展,微服务之间的沟通关系开始变得复杂,一个业务的实现往往是途径了很多个微服务,然而冗长的调用链带来的是数倍增长的排错难度。

    举个例子:一个业务需要经过10个微服务的逻辑处理才能返回最终结果,某一个时间段依据用户反馈,这个业务已经无法正常运转,此时研发人员需要地毯式排查每一个经过的业务服务,才能准确的知道故障源。

    故障定位一直以来都是一件麻烦事,在微服务架构下排错更是需要支付高昂的成本。

    当故障出现时难以确定影响范围

    虽然在微服务架构下,单点故障难以对系统造成整体上的破坏,但业务从来都不是独立完成的,各服务之间存在各式各样的依赖关系,这就导致故障出现时往往会级联影响到下游业务,甚至引发其他业务的连锁故障,此时业务最终呈现的现象往往会干扰研发人员对其故障范围的判断。

    微服务架构在部署环境中的故障难以复现

    微服务架构下的服务调度错综复杂,一个业务故障的产生往往与其上下游的服务有很大的关系。有时我们在本地测试一切正常,但放到环境当中运行时却会引发故障,其原因或许是部署的环境有问题,亦或许是下游服务给予了一些意外的参数,亦或许是上游服务响应的结果不符合预期,此类种种都是我们在离开了部署环境时很难预料到的变故,并且在微服务架构的掩盖下,复现故障十分困难。

    总结

    微服务架构是解决业务复杂度的一个很好的方法,也是目前企业实践中最常用的办法。但是由于微服务架构的复杂性,企业想要管理好基于微服务架构的应用,也需要具备更高的能力。如果微服务治理得不恰当,反而有可能适得其反,不仅不能享受到微服务架构带来的好处,反而会因为微服务带来的系统复杂性,造成开发、运维部署的复杂度增加,进⽽影响开发迭代的速度,甚至影响系统的整体稳定性。

    综上所述,企业对微服务治理的需求是十分明确的,就是想知道当下环境当中,特别是在数量庞大的微服务相互沟通的过程中,到底发生了什么,当故障发生时,故障的影响范围,故障的根本原因,最后是需要解决或缓解故障对业务影响的手段。

    目前主流的服务治理解决思路

    以SDK为主要表现形式的研发侧解决思路

    通过编码的方式,让我们的业务代码直接具备解决问题的手段,这是目前最主流的也是发展时间最长的一种解决问题的思路。

    spring

    研发的思维十分纯粹且直白,既然需要服务治理的能力,那就直接将这种能力写在代码上。通过日积月累沉淀出一些好用的SDK,代码只需要引入这些SDK即可获得服务治理能力。

    在这条思路上最出名的开源库是SpringCloud。作为微服务治理框架的集合,SpringCloud的核心库封装了包括服务发现、流量访问、网关路由、熔断器、链路追踪等能力。

    使用SDK解决服务治理的思路优势是:研发可以完全的掌握服务治理的所有能力,能够根据实际需求进行定制化,使其更加适配企业的实际情况。并且经过经年累月的打磨,部分语言的治理框架已经比较完善,为研发后续的开发打下了坚实的基础。

    缺点是:研发掌握了一切,一旦SDK内部逻辑出现故障,或者是需要升级,就必须让研发介入重新编译打包,并且由于大部分服务都接入了服务治理SDK,所以一次升级可能需要涉及到很大范围的重新部署,这样做风险很大。SDK具备语言相关的属性,虽然部分语言的治理框架相对完善,但仍有很多流行的编程语言缺少完善的治理库,如果企业内部语言较多,为了平衡各类治理框架的差异,做统一管理,就需要投入额外的开发成本。

    以Sidecar为主要表现形式的运维侧解决思路

    随着技术的快速发展,DevOps理念开始流行,一种以Sidecar为主要表现形式的运维侧解决思路开始出现。研发只需要关注自身的业务部分,服务治理能力通过其他工具插入到正在运行的业务服务当中。

    istio架构
    Sidecar模式,指单独将能力封装在另一个程序当中与业务共同运行,以此来增强业务服务的能力。服务网格(Service Mesh)技术就大量的使用了Sidecar模式,其中最为著名的开源库是Istio。

    使用Sidecar模式解决服务治理的思路优势是:Sidecar作为基础设施可以由运维人员完全掌控,它与编程语言无关,并且完美的规避了SDK升级带来的重新编译部署的烦恼,并且由于Sidecar完全独立于业务服务,这就赋予业务在任何时间接入和任何时间退出的权利,即插即用。

    与之相对的是Sidecar模式的缺陷:Sidecar必须劫持流量才可以做到对业务服务的能力增强,这就意味着在业务调度的过程中产生了一个新的不确定因素,一旦Sidecar本身出现故障,它将影响业务的正常运转。其次,在路由中每个服务都多了一跳,这就导致Sidecar必然带来性能的损耗。

    以SDK与Sidecar同时存在为主要表现形式的解决思路

    在云原生理念的推动下,业界又诞生了一种新的解决思路,它融合了SDK和Sidecar这2种解决问题的想法,并且期望实现完全的云原生,这就是Dapr。
    Dapr

    Dapr 是微软主导的云原生开源项目,2019年10月首次发布,到今年2月正式发布 V1.0 版本。在不到一年半的时间内,Github star 数达到了1.2 万,发展势头迅猛,Dapr 这个词是是「Distributed Application runtime」的首字母缩写:dapr是一个为应用提供分布式能力的运行时。

    准确来说Dapr并不单单解决服务治理问题,而是完全基于云原生理念诞生的产物,Dapr希望将一切都抽象成云资源,代码通过对云资源的依赖来实现相应的业务。为了让各种语言都有统一的实现规范,Dapr给很多流行的语言提供了SDK,又结合了Sidecar思想,将真正实现逻辑的部分都封装在Sidecar当中,此时的Sidecar就是Dapr的运行时,有多个Sidecar,那就会出现多个运行时。业务代码会先通过SDK沟通Sidecar,再历经各个Sidecar的相互作用来实现具体需求,其中就包含了服务治理能力。

    这种解决问题的办法有一个重要的优势:Dapr不仅可以动态的添加包含服务治理能力在内的各项公共能力,还可以基于抽象的云资源实现对底层实现的替换,比如将MongoDB替换成Redis等。

    然而这种方式的缺陷也十分明显:Dapr几乎包含了SDK模式和Sidecar模式的大多缺点,SDK如果无法匹配Sidecar的版本时同样面临着SDK升级困难问题。由于多运行时共同作用,在路由上流量每经过一个服务,可能多了不止一跳,同样面临着性能问题。由于逻辑都封装在Sidecar上,也避免不了Sidecar本身故障时无法正常访问,并且由于多运行时,当故障出现很难准确定位故障。

    如何抉择

    SDK的方式和企业业务最贴合,完全的自主可控,可是需要付出巨大的研发和维护代价,去实现服务治理相应的功能。

    Dapr的理念十分前卫,它能提供更多的想象空间,但是如果使用Dapr结构,研发需要放弃经营已久的开发框架去适配Dapr,相当于把底层框架几乎换掉,这个代价不是大多数企业能够承受的。

    从企业成本付出来看,服务网格或许是现阶段最适合的解决方案。

    使用服务网格解决微服务治理问题是当下代价最小的解决方案

    服务网格(Service Mesh)是Sidecar模式的代表型技术之一,是处理服务间通信的基础设施层,在实践中,服务网格通常以轻量级网络代理阵列的形式实现,这些代理与应用程序代码部署在一起。作为云原生的网络基础设施,它把微服务调度中有关网络的公共能力下沉到代理,实现了在无任何代码侵入的情况下提供可观察性、流量管理和安全性等能力。

    相比SDK和Dapr这种需要研发深度介入的解决问题思路,服务网格的使用代价相对最小,这取决于Sidecar模式带来的结构优势:

    • 零侵入,业务无感知,不需要支付额外的研发成本。
    • 语言无关,无论使用任何编程语言都可以享受统一的服务治理能力。
    • 升级便利,作为独立第三方服务,服务网格的升级迭代并不会影响业务的正常运行。

    服务网格即插即用的特质对于企业十分友好,特别是针对组织架构相对复杂的企业,越少的部门关联意味着越少的沟通成本,而部门之间的沟通几乎是企业成本最大的地方。

    综上所述,使用服务网格解决企业微服务治理是现阶段代价最小的选择,也是最推荐的解决方案。

    更多相关内容
  • 本课程共分为以下几个部分来讲解:yaf框架深入剖析,搭建企业内部私有composer库,自己编写ORM框架,console应用,yar微服务框架及案例,redis、yac通用二级缓存,基于yaf、redis、yar框架生产者/消费者模式通用任务消费...
  • 根据实际业务,亿万级互联网架构设计,基于JAVA语言,结合springcloud Alibaba微服务,涵盖微服务治理、服务监控、系统监控、监控大屏、高可用微服务框架、Jenkins 自动化CI/CD、容器自动化等
  • 什么叫做微服务?这是Martin提出来的一个概念,它是一种将应用构建成一系列按业务领域划分模块的,小的自治服务的软件架构方式,倡导将复杂的单体应用拆分成若干个功能单一、松偶合的服务,这样可以降低开发难度、...
  • 微服务和中台是这几年非常时髦随处可见的词,最先在一批互联网企业中开始谈论和建设,并逐渐的蔓延至一些传统企业和传统的IT部门,以至于现在在构建信息系统时,很多企业都在说要建一个中台,但究竟要建成什么样还...
  • 2019年10月 最新 微服务 容器技术 青云企业微服务改造服务
  • 用友云服务治理平台助力企业微服务架构落地.pdf
  • 基于springCloud+zipkin+zull网关搭建的一套企业微服务框架 集成很多基础功能,适合有一定微服务基础的同学参考和研究
  • 《大型企业微服务架构实践与运营》,以实例和技术穿插的方式,讲解了微服务、kubernets的知识,爱好这方面的IT同仁,可以看看
  • 企业微服务架构实践.docx
  • 企业微服务架构设计方案.docx
  • 企业微服务落地实践分析.docx
  • 企业微服务转型Devops实践.pptx
  • 企业微服务架构落地方案.pptx
  • 企业微服务技术架构介绍.pptx
  • 企业微服务技术架构介绍.pdf
  • 企业微服务技术最佳实践.pptx
  • 企业微服务技术最佳实践.pdf
  • 企业微服务技术架构演进方案.pdf
  • 企业微服务架构转型最佳实践.pptx
  • 企业微服务技术架构演进方案.docx
  • 企业微服务技术架构实践参考.pdf
  • 基于广电网络的企业微服务小程序的设计与实现.pdf
  • 企业微服务架构中的基础设施.pptx
  • TanZu Spring Runtime构建企业 微服务应用架构 提供企业核心应用构建过程中最常用基础软件包和技术专家服务的组合 VMwares Java&Spring Experts Support 24/7 Simple Pricing 2 VMware Tanzu Spring Runtime 解决...
  • ;20
  • 企业微服务架构设计及实施的六大难点剖析-最佳实践.docx
  • ;VMware/Pivotal Spring Runtime: 包含的产品及服务;...VMware SpringRuntime 软件包以及技术支持 微服务构建的兵器库;VMWare Spring Runtime持续创新推动企业级软件开发;VMWare Spring的项目和技术趋势;Sp

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 91,044
精华内容 36,417
关键字:

企业微服务