关于Servicemesh是什么,能做什么,此处不再进行赘述,相关文章已经非常之多。读者可以自行上网查阅。Servicemesh是一个比较新的名词,在2017年才逐步传播开来。之前主要集中于各种云服务的解决方案中使用。我们在开始阐述Servicemesh之前,先来系统地回顾下微服务的发展历程,其更有助于我们对Servicemesh的了解。以下会根据我实际的经验,以及一些方法论,来穿插推进论证整个发展历程。
1.1 MVP阶段
在初始阶段,为了追求最高效率的快速试错和产品迭代,几乎所有的公司的技术架构最开始都是这么演进过来的。从自身经历来,举几个例子。
- 百度凤巢。百度广告系统。主系统mercury,里面集成了报表、广告优化推荐、物料管理、历史操作记录、平台产品等等一系列的凤巢广告库核心业务功能,基于当时时下最流行的OSGI架构进行bundle化部署运维。这在一开始给我们带来了很大的便利,包括快捷的开发速度,无需复杂的RPC服务治理,技术栈一致性的保障,但随着业务规模的快速扩张,带来的冲突同时也避无可避,如如何进行项目管理、代码分支管理、代码冲突解决、测试环境冲突、上线竞争、生产环境相互之间的影响,都严重影响了开发和生产效率。MVP于此也将结束他的历史使命。
- 丁丁租房。长期盘踞北京房租整租垂类Top1(后面被链家收回关停),2015年春节推出一炮而响,但是随之而来的是各种源源不断的技术负面新闻如APP莫名其妙崩溃,卡顿等等。2015年5月份时,主系统GMS里面集成了经纪人管理、各角色带看、交易、订单、支付主逻辑。其带来的便利,以及随着业务增长带来的问题和上面所述如出一辙,此处不复赘述。
- 猫眼娱乐。猫眼电影作为电影在线票务Top1,在2013年至今,保持着快速的增长。但是同时其也经历了同样的过程。其也保持了刚开始All In One的快速迭代思想,主系统MovieSRV,集成了基本电影选座的所有功能,随着业务发展,在2014年变形金刚4上映期间,由于流量过大,耦合业务之间相互影响,导致服务jetty资源耗尽,整体不可用数个小时。其带来了巨大的损失。
以上例子,综上所述来看,MVP在业务快速试错迭代的初期,确实是需要以MVP方式来进行快速试错,但业务快速增长和团队规模的持续增大,必然会直接带来MVP模式所产生的所有恶果,历史总是惊人的相似,而我们能够做的事情有哪些呢?
1.2 微服务
当All In One的模式进行不下去的时候,暴力美学告诉我们,那就拆。于是,我们水平拆分、垂直拆分、领域驱动、单一职责服务,越来越细,而我认为所谓微服务,即越拆越细的服务化架构,及与此匹配的基础设施能力的构建。
百度凤巢也不例外,抛弃了沉重的OSGI框架,由ClassLoader级别的隔离转向了物理隔离,自研类Dubbo的服务治理框架Stargate,全面拥抱微服务,拆分出了广告核心、账户优化、报表、平台、历史操作记录。
丁丁租房进行了“蓝莲花”项目的全面重构,进行了经纪人、联系、人、房、交易、支付等模块的全面服务化,并进行了基础设施的全面自建如Smart-Codis、API Gateway、私有云等。
猫眼娱乐则在变4事故之后,展开了“帝国余晖”项目,进行了订单、支付、券、活动、交易、价格、会员卡等系统的全面拆分服务化。
微服务伴随着越拆越细的进程,且与之带来的运维和整体系统上把控的难度也指数级上升,我们能否handle住以及如何handle住这样的变化呢?
1.3 后微服务时代
随着服务化不断深入,服务拆分不断细化,我们面临着非常复杂的服务拓扑的场景下,如何进行服务治理,即进行分布式服务调用、链路追踪、流控、鉴权、熔断、隔离、降级、监控报警,以及完善与之配套的运维能力呢?服务治理是一个环,其正向治理和逆向反馈的能力随着服务规模的不断膨胀,其带来的心智成本和运维成本将会在某个临界点呈爆发式地增长,而我们不得不为其付出昂贵地代价。
那,我们应该怎么办呢?微服务的方法论有很多,此处我先抛出三个方法论,其侧面印证了微服务后续的演进路线,而实际上,微服务确实是在这么演进的。
1.3.1 虚拟化,标准化,产品化
只有进行虚拟化,才能将复杂异构层出不穷的问题标准化,只有进行了标准化,我们才能将功能产品化,只有产品化,我们才能确保我们功能的可持续健康发展。
虚拟化,标准化和产品化,其实一直是贯穿整个现代互联网体系架构的全过程。DNS虚拟化了IP和负载策略的细节,四层七层负载虚拟化了服务端的细节,访问缓存常用的一致性哈希环虚拟节点也用了虚拟化来规避雪崩等复杂场景,我们的分布式服务调用虚拟化了Provider集群的细节,我们访问数据库利用中间件虚拟化了读写分离和分库分表逻辑,甚至你可以认为你的几十种设计模式,说到底都是在进行虚拟化你的各种异构实现。虚拟化是一切之基石,它其实在我们的潜意识中如此根深蒂固以至于我们都以为理所应当。
1.3.2 程序包含环境,而非剥离环境
我们一点点来分析,微服务基础设施的一个非常重要的症结其实在环境与程序的剥离。怎么说?环境与程序剥离,会带来大量的问题,比如
- dev、test、stage、product环境和程序不一致可能会引发测试没问题,上线就出问题的各种诡异场景,追查到最后可能就是一个环境变量、目录权限、机器配置文件地址差异等原因所导致的。
- 一些基础设施不可避免的需要在机器上部署一些脚本、agent,比如zabbix,比如sidecar,如果将这些脚本、agent在机器初始化阶段通过pxe、ansible、puppet等工具进行安装,而等到服务真正要使用的时候,这个时间差的周期里面可能会由于升级等原因导致不一致的情况发生,在两个非常大的时间跨度(机器上架初始化与服务上线)里去完成两件紧密耦合的事情,其也客观上增大了微服务基础设施运维和研发协作的成本。
- 你这个程序需要JDK1.7的支持才能启起来,怎么传达这个信息给运维,口头,文档?发布系统勾选一下选项?如果是其他的依赖呢比如ImageMagic?以后如何始终确保继任者清晰认识这个前置条件?
所以,我们可以明显地看出来,无论是业务程序还是基础设施程序,我们都需要让程序囊括环境去结合考虑,而不是如传统的做法一样,剥离环境与程序。我们应该意识到,环境和程序是一体的,缺少任意一方,功能将不再完整。
1.3.3 少惯“宠物”,多养“奶牛”,权衡而非对抗
你有一只宠物,也有一只奶牛,宠物生病了,你很着急地想要治好它,而奶牛生病了,你就杀了它卖掉。pets-vs-cattle理论其实在于一个权衡,也侧面提醒我们,越少不可代替的服务,你的服务就越可控。最理想情况下,我们希望一切都快速失败重头再来,没有什么是不可替代的。对于服务,我们可以采用一些更直接的灾备方案,比如快速切换,比如分流限流等手段,来保障我们可以快速重启,并尽可能做少流量损失,而不是寄希望于其永远不挂,因为这是不可能的。
pets-vs-cattle理论的提出是希望我们不要对服务分三六九等来增加服务运维管理的复杂度,其本身也无可厚非,但这么做有点“大跃进”之嫌,我们还是应该秉持更加客观可落地的方案去推进,适当进行权衡,而不是一味否定或激进地肯定。大方向是没有问题的,少惯些“宠物”,多养些“奶牛”
基于以上方法论,下一代的微服务也便呼之欲出了。(未完待续)
相关推荐
Service Mesh 的工作方式简单来说,就是将原本嵌入应用的微服务 Client 独立了出来,作为一个 Proxy 进程独立运行于每一台应用主机上。应用仅需简单地配置一个本地 Proxy 地址进行调用,由本机 Proxy 通过下发的服务...
综上所述,Service Mesh在有赞的实践与发展涉及了服务架构的全面转型,从单体服务到微服务的拆分,以及在这个过程中,如何使用各种工具和组件来解决开发、部署、监控、安全性等方面的问题。通过这些实践,有赞能够更...
1. 不需要为多种语言编写微服务框架代码,因为Service Mesh提供了统一的网络通信能力。 2. Service Mesh对业务代码是无侵入的,这样便于快速迭代和更新服务。 3. Service Mesh适合于不适合改造的单体应用,能帮助...
Service Mesh作为下一代微服务架构的重要组成部分,已经在蚂蚁金服的IT系统中发挥了关键作用。2017年起,蚂蚁金服开始探索Service Mesh技术,逐步将其发展为未来的技术方向。从技术预研到大规模落地,蚂蚁金服经历了...
Service Mesh发展趋势:云原生领域的核心支柱 敖小剑在演讲中探讨了Service Mesh的发展趋势,特别是针对Istio这一Service Mesh实现的架构与性能之间的权衡。Service Mesh作为云原生架构的重要组成部分,它的设计...
Service Mesh的发展路径通常涉及多语言、异步架构的并存,协议的多样化,以及存量服务的平滑迁移。随着技术的成熟,监管控体系会更加完善,同时保持应用和平台的独立发展与演进,最终实现技术的全面更新换代。 ...
### Service Mesh 的本质...综上所述,Service Mesh 不仅为企业级微服务架构提供了新的解决方案,也展示了未来分布式系统的广阔前景。随着技术的不断发展和完善,我们有理由相信 Service Mesh 将在未来发挥更大的作用。
- **服务网格**(Service Mesh)是现代云原生应用的重要组成部分,它通过解决服务间通信的关键问题,帮助组织构建更加健壮、灵活和安全的微服务架构。 - **Istio** 作为服务网格领域的领导者之一,为开发者提供了...
综上所述,蚂蚁金服在Service Mesh的部署过程中采取了一系列有序的步骤,既考虑到了技术的实际可行性,又充分考虑了业务发展的需求,最终形成了一套完整的迁移方案。这一过程不仅体现了蚂蚁金服对于技术创新的态度,...
2. **技术选型**:探讨了各种用于实现微服务的技术,如Spring Boot、Docker、Kubernetes、 Istio、Service Mesh、API Gateway等,以及它们在微服务架构中的角色。 3. **微服务开发流程**:讲解如何进行服务的开发、...
- Service Mesh:如Istio,构建在Kubernetes之上,提供更细粒度的服务治理和监控。 6. **Kubernetes在云平台的应用** - **多云策略**:Kubernetes可以帮助企业在多个云提供商之间无缝迁移和扩展。 - **持续集成/...
云原生架构的定义涉及到一系列技术,包括但不限于容器技术、微服务、Serverless和Service Mesh。容器技术,尤其是Docker,为应用程序提供了轻量级的虚拟化环境,使得应用可以在不同环境中无缝迁移。微服务架构将大型...
容器技术如Docker和Kubernetes简化了应用部署,Service Mesh如Istio则集中管理微服务治理。 3. 数据架构:随着业务运行,数据积累并需被有效利用。企业从简单的数据记录发展到构建数据仓库、BI系统,实现数据驱动的...
重磅,史上最全的阿里云分享的云原生技术学习资料合集,共120份。 一、阿里云开源书合集 2020微服务领域开源数字化报告 阿里巴巴云原生技术与实践13讲 阿里巴巴云原生实践15讲 不一样的双11技术:阿里巴巴经济体云...
云原生架构强调的是以容器技术、微服务、Serverless、开放应用模型(OAM)、ServiceMesh技术和DevOps等为核心的架构模式。这些技术共同作用,促使业务和应用开发更加灵活、可靠,并且具备快速迭代的能力。 阿里巴巴...
1. 多种监控方式,可以通过语言探针和 Service Mesh 获得监控的数据。 2. 支持多种语言自动探针,包括 Java、.Net Core、Node.js。 3. 轻量高效,无需大数据平台和大量服务器资源。 4. 模块化,UI、存储、集群管理都...
- Service Mesh(服务网格)是一种用于处理服务间通信的基础设施层,它通过在微服务架构中的服务之间提供动态、可发现和安全的通信路径来实现。 - Service Mesh通常以轻量级网络代理的形式存在,这些代理被部署为...
6. **服务网格化**(Service Mesh): - **定义**:最早由开发Linkerd的Buoyant公司提出,指一个基础设施层,专门处理服务间的通信,职责是负责实现请求的可靠传递。 - **特点**: - 在实践中,服务网格通常实现...