专栏首页橙子架构杂谈【Servicemesh系列】【章1】微服务发展路径(上)

【Servicemesh系列】【章1】微服务发展路径(上)

关于Servicemesh是什么,能做什么,此处不再进行赘述,相关文章已经非常之多。读者可以自行上网查阅。Servicemesh是一个比较新的名词,在2017年才逐步传播开来。之前主要集中于各种云服务的解决方案中使用。我们在开始阐述Servicemesh之前,先来系统地回顾下微服务的发展历程,其更有助于我们对Servicemesh的了解。以下会根据我实际的经验,以及一些方法论,来穿插推进论证整个发展历程。

1.1 MVP阶段

在初始阶段,为了追求最高效率的快速试错和产品迭代,几乎所有的公司的技术架构最开始都是这么演进过来的。从自身经历来,举几个例子。

  1. 百度凤巢。百度广告系统。主系统mercury,里面集成了报表、广告优化推荐、物料管理、历史操作记录、平台产品等等一系列的凤巢广告库核心业务功能,基于当时时下最流行的OSGI架构进行bundle化部署运维。这在一开始给我们带来了很大的便利,包括快捷的开发速度,无需复杂的RPC服务治理,技术栈一致性的保障,但随着业务规模的快速扩张,带来的冲突同时也避无可避,如如何进行项目管理、代码分支管理、代码冲突解决、测试环境冲突、上线竞争、生产环境相互之间的影响,都严重影响了开发和生产效率。MVP于此也将结束他的历史使命。
  2. 丁丁租房。长期盘踞北京房租整租垂类Top1(后面被链家收回关停),2015年春节推出一炮而响,但是随之而来的是各种源源不断的技术负面新闻如APP莫名其妙崩溃,卡顿等等。2015年5月份时,主系统GMS里面集成了经纪人管理、各角色带看、交易、订单、支付主逻辑。其带来的便利,以及随着业务增长带来的问题和上面所述如出一辙,此处不复赘述。
  3. 猫眼娱乐。猫眼电影作为电影在线票务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 程序包含环境,而非剥离环境

我们一点点来分析,微服务基础设施的一个非常重要的症结其实在环境与程序的剥离。怎么说?环境与程序剥离,会带来大量的问题,比如

  1. dev、test、stage、product环境和程序不一致可能会引发测试没问题,上线就出问题的各种诡异场景,追查到最后可能就是一个环境变量、目录权限、机器配置文件地址差异等原因所导致的。
  2. 一些基础设施不可避免的需要在机器上部署一些脚本、agent,比如zabbix,比如sidecar,如果将这些脚本、agent在机器初始化阶段通过pxe、ansible、puppet等工具进行安装,而等到服务真正要使用的时候,这个时间差的周期里面可能会由于升级等原因导致不一致的情况发生,在两个非常大的时间跨度(机器上架初始化与服务上线)里去完成两件紧密耦合的事情,其也客观上增大了微服务基础设施运维和研发协作的成本。
  3. 你这个程序需要JDK1.7的支持才能启起来,怎么传达这个信息给运维,口头,文档?发布系统勾选一下选项?如果是其他的依赖呢比如ImageMagic?以后如何始终确保继任者清晰认识这个前置条件?

所以,我们可以明显地看出来,无论是业务程序还是基础设施程序,我们都需要让程序囊括环境去结合考虑,而不是如传统的做法一样,剥离环境与程序。我们应该意识到,环境和程序是一体的,缺少任意一方,功能将不再完整。

1.3.3 少惯“宠物”,多养“奶牛”,权衡而非对抗

你有一只宠物,也有一只奶牛,宠物生病了,你很着急地想要治好它,而奶牛生病了,你就杀了它卖掉。pets-vs-cattle理论其实在于一个权衡,也侧面提醒我们,越少不可代替的服务,你的服务就越可控。最理想情况下,我们希望一切都快速失败重头再来,没有什么是不可替代的。对于服务,我们可以采用一些更直接的灾备方案,比如快速切换,比如分流限流等手段,来保障我们可以快速重启,并尽可能做少流量损失,而不是寄希望于其永远不挂,因为这是不可能的。

pets-vs-cattle理论的提出是希望我们不要对服务分三六九等来增加服务运维管理的复杂度,其本身也无可厚非,但这么做有点“大跃进”之嫌,我们还是应该秉持更加客观可落地的方案去推进,适当进行权衡,而不是一味否定或激进地肯定。大方向是没有问题的,少惯些“宠物”,多养些“奶牛”

基于以上方法论,下一代的微服务也便呼之欲出了。(未完待续)

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 【大型网站技术架构笔记】(四)伸缩性、可扩展性与安全

    一般手段有两种。一类是根据功能进行物理分离,一类是对单一功能进行集群化来实现。比如将缓存、静态文件、数据库服务从服务器中拆分进行单独部署,比如对业务逻辑进行横向...

    吃橙子的狐狸
  • 【SEDA异步框架】【四】异步框架总体设计与实现

           前文提到,基于SEDA的异步框架,一个stage的理想结构描述如下:

    吃橙子的狐狸
  • 【大型网站技术架构笔记】(三)高性能与高可用架构

    1.响应时间。 2.并发数。如果暂时没有对应的准确监控,针对不同业务模型,可以有不一样的并发数的预估。我们的系统进行峰值并发数预估的话,有一种比较粗略的计算...

    吃橙子的狐狸
  • 跟我学Spring Cloud(Finchley版)-04-服务注册与服务发现-原理剖析

    地址硬编码问题——电影微服务中将用户微服务的地址写死,如果用户微服务地址发生变化,难道要重新上线电影微服务吗?

    用户1516716
  • dll依赖查看工具-depends

    版权声明:本文为博主原创文章,转载请注明出处。 https://blog.csdn.net/...

    chaibubble
  • 微服务到底该多大?如何设计微服务的粒度?

    微服务实践最常见的错误之一是把微服务做得过小。本文通过示例,深入讨论了微服务的大小和粒度。

    用户2781897
  • Python的初学者你现在可以自己“看”到代码的运行了!

    最近小编一直在给群里小伙伴解决各种的错误,尤其是对一些基础薄弱的同学来说,出现错误后更是一脸懵逼!直到有一天,小编找到了Python Tutor,终于解脱了。

    云飞
  • Dubbo剖析-服务提供方Invoker到Exporter的转换

    前面dubbo整体架构分析里面我们讲解了服务提供者暴露一个服务的详细过程是,首先具体服务的实现类转换为了Invoker对象,然后Invoker在转换为Expor...

    加多
  • 「 从0到1学习微服务SpringCloud 」01 一起来学呀!

    有想学微服务的小伙伴没?一起来从0开始学习微服务SpringCloud,我会把学习成果总结下来,供大家参考学习,有兴趣可以一起来学!如有错误,望指正!

    KEN DO EVERTHING
  • SpringCloud组件:Eureka服务注册中心的失效剔除与自我保护机制

    Eureka作为一个成熟的服务注册中心当然也有合理的内部维护服务节点的机制,比如我们本章将要讲解到的服务下线、失效剔除、自我保护,也正是因为内部有这种维护机制才...

    恒宇少年

扫码关注云+社区

领取腾讯云代金券