关于Servicemesh是什么,能做什么,此处不再进行赘述,相关文章已经非常之多。读者可以自行上网查阅。Servicemesh是一个比较新的名词,在2017年才逐步传播开来。之前主要集中于各种云服务的解决方案中使用。我们在开始阐述Servicemesh之前,先来系统地回顾下微服务的发展历程,其更有助于我们对Servicemesh的了解。以下会根据我实际的经验,以及一些方法论,来穿插推进论证整个发展历程。
在初始阶段,为了追求最高效率的快速试错和产品迭代,几乎所有的公司的技术架构最开始都是这么演进过来的。从自身经历来,举几个例子。
以上例子,综上所述来看,MVP在业务快速试错迭代的初期,确实是需要以MVP方式来进行快速试错,但业务快速增长和团队规模的持续增大,必然会直接带来MVP模式所产生的所有恶果,历史总是惊人的相似,而我们能够做的事情有哪些呢?
当All In One的模式进行不下去的时候,暴力美学告诉我们,那就拆。于是,我们水平拆分、垂直拆分、领域驱动、单一职责服务,越来越细,而我认为所谓微服务,即越拆越细的服务化架构,及与此匹配的基础设施能力的构建。
百度凤巢也不例外,抛弃了沉重的OSGI框架,由ClassLoader级别的隔离转向了物理隔离,自研类Dubbo的服务治理框架Stargate,全面拥抱微服务,拆分出了广告核心、账户优化、报表、平台、历史操作记录。
丁丁租房进行了“蓝莲花”项目的全面重构,进行了经纪人、联系、人、房、交易、支付等模块的全面服务化,并进行了基础设施的全面自建如Smart-Codis、API Gateway、私有云等。
猫眼娱乐则在变4事故之后,展开了“帝国余晖”项目,进行了订单、支付、券、活动、交易、价格、会员卡等系统的全面拆分服务化。
微服务伴随着越拆越细的进程,且与之带来的运维和整体系统上把控的难度也指数级上升,我们能否handle住以及如何handle住这样的变化呢?
随着服务化不断深入,服务拆分不断细化,我们面临着非常复杂的服务拓扑的场景下,如何进行服务治理,即进行分布式服务调用、链路追踪、流控、鉴权、熔断、隔离、降级、监控报警,以及完善与之配套的运维能力呢?服务治理是一个环,其正向治理和逆向反馈的能力随着服务规模的不断膨胀,其带来的心智成本和运维成本将会在某个临界点呈爆发式地增长,而我们不得不为其付出昂贵地代价。
那,我们应该怎么办呢?微服务的方法论有很多,此处我先抛出三个方法论,其侧面印证了微服务后续的演进路线,而实际上,微服务确实是在这么演进的。
只有进行虚拟化,才能将复杂异构层出不穷的问题标准化,只有进行了标准化,我们才能将功能产品化,只有产品化,我们才能确保我们功能的可持续健康发展。
虚拟化,标准化和产品化,其实一直是贯穿整个现代互联网体系架构的全过程。DNS虚拟化了IP和负载策略的细节,四层七层负载虚拟化了服务端的细节,访问缓存常用的一致性哈希环虚拟节点也用了虚拟化来规避雪崩等复杂场景,我们的分布式服务调用虚拟化了Provider集群的细节,我们访问数据库利用中间件虚拟化了读写分离和分库分表逻辑,甚至你可以认为你的几十种设计模式,说到底都是在进行虚拟化你的各种异构实现。虚拟化是一切之基石,它其实在我们的潜意识中如此根深蒂固以至于我们都以为理所应当。
我们一点点来分析,微服务基础设施的一个非常重要的症结其实在环境与程序的剥离。怎么说?环境与程序剥离,会带来大量的问题,比如
所以,我们可以明显地看出来,无论是业务程序还是基础设施程序,我们都需要让程序囊括环境去结合考虑,而不是如传统的做法一样,剥离环境与程序。我们应该意识到,环境和程序是一体的,缺少任意一方,功能将不再完整。
你有一只宠物,也有一只奶牛,宠物生病了,你很着急地想要治好它,而奶牛生病了,你就杀了它卖掉。pets-vs-cattle理论其实在于一个权衡,也侧面提醒我们,越少不可代替的服务,你的服务就越可控。最理想情况下,我们希望一切都快速失败重头再来,没有什么是不可替代的。对于服务,我们可以采用一些更直接的灾备方案,比如快速切换,比如分流限流等手段,来保障我们可以快速重启,并尽可能做少流量损失,而不是寄希望于其永远不挂,因为这是不可能的。
pets-vs-cattle理论的提出是希望我们不要对服务分三六九等来增加服务运维管理的复杂度,其本身也无可厚非,但这么做有点“大跃进”之嫌,我们还是应该秉持更加客观可落地的方案去推进,适当进行权衡,而不是一味否定或激进地肯定。大方向是没有问题的,少惯些“宠物”,多养些“奶牛”
基于以上方法论,下一代的微服务也便呼之欲出了。(未完待续)