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

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