为了搞懂“云原生”，女朋友竟敢让我悬梁刺股？！

  自从成功躲过“大数据”、“数据孤岛”等概念坑后，女朋友仿佛并没有真正的臣服，甚至有些变本加厉!这次竟然用“云原生”刁难我，并冠以“搞不懂它，承包一个月的家务”、“必要时头悬梁锥刺股”、“或者背诵《般若波罗蜜多心经》”等苛刻条件。

 

  太过分了!“观自在菩萨，行深般若波罗蜜多时，照见五蕴皆空，度一切苦厄......”磕磕绊绊读过《心经》之后，我还是乖乖地选择了女朋友挖的坑——让女朋友彻底理解云原生。毕竟，逃避解决不了任何问题，反而会制造更多焦虑。

 

  于是，我开始苦思冥想、悬梁刺股，开始研究“怎么才能把云原生说的更直白、更透彻”。白驹过隙、斗转星移，这一天我真正掌握了内功心法，进行了一场家庭版脱口秀——《白话云原生》。

  故事是从这里开始的。2013年Cloud Native之父MattStine，拍了拍脑门，把在Pivotal的架构、咨询经验进行系统总结，提出Cloud Native这个词汇。这个英文单词翻译过来，就是云原生(Cloud是云;Native是原生)。遗憾的是Cloud Native提出来的时候，并没有明确的释义，仅仅知道它是个包括DevOps(开发运维)、持续交付、微服务等在内的思想集合。 

  这就尴尬了。没有明确定义，意味着“仁者见仁，智者见智”，每个云计算企业都可以自行定义，这也代表着云原生并没有一个统一的标准。不过，为了能让女朋友了解云原生，我还是使劲了浑身解数，竭尽全力地去胡诌。

  Cloud Native可以拆解成Cloud(云/云环境/云计算)、Native(本地的/当地的/原生的/土著的)。可以发散一下思维，Cloud Native在翻译的时候并没有翻译成云土著、云当地、云本地这些特别别扭的名字，叫了一个特别优雅响亮的名字——云原生。

  为了更好地理解云原生，我得借用《晏子使楚》里的“橘生淮南则为橘，生于淮北则为枳”，它的意思是，淮南的橘树，移植到淮河以北就变为枳树。因此，对于橘树来讲，淮南是它的原生地，淮北是它的迁徙地。按照这个原理来推算，云原生就是为云坏境而生，就是云坏境当地的软件架构，其在设计之初便考虑了云环境。与此同时，那些设计之初没有考虑云环境的本地部署的软件架构需要进行迁移，这就叫云迁移。

 

 

  时光荏苒、白驹过隙、斗转星移。当年提出的“云原生”在云计算时代的价值愈发得到彰显，原来依靠云迁移的路线，并不能百分之百考虑到云原生环境，毕竟“橘生淮南则为橘，生于淮北则为枳”，难免水土不服。直到2015年的某一天，Google牵头成立了云原生计算基金会，简称CNCF。这下不妙了，CNCF都成立了，云原生的定义还没明确，这难免有些说不过去。从这天开始，CNCF日夜苦思冥想：云环境和本地得有区别吧;软件架构在本地部署和云上部署也得有区别吧;云原生到底有哪些技术更有利于云的发展。于是，CNCF用容器化、微服务、编排调度定义了云原生。

  别急，容器化、微服务等专业词汇将在下文统一讲述。

  再一次时光荏苒、白驹过隙、斗转星移。各类的云计算厂商发现，CNCF对云原生的定义，并没有那么强烈的说服力。每个厂商依旧在玩自己的云原生，都在用实际行动做自己的云原生。这可怎么办？既然没有统一的定义，那我们就默认统一一下云原生的四大核心要素(微服务技术、DevOps、持续交付、容器化)吧!满足四大核心要素，你做的就是云原生!

  说了这么多，我也想用最简单的话语概括云原生，这里请允许我借用华为对云原生下的定义：采用开源堆栈(K8S+Docker)进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。 

  “Wait，微服务、DevOps、持续交付、容器化是什么？”女朋友投来疑惑的眼神，面庞透过丝丝焦虑，紧接着问：“为什么满足上述四要素就基本上是云原生了？”

  我......

  好吧，帮人帮到底，送佛送到西。

  微服务技术

  微服务就是一个独立发布的应用服务，可以作为独立组件升级、灰度或复用等，每个服务可以由专门的组织来单独完成，依赖方只要定好输入和输出口即可完全开发，甚至整个团队的组织架构更精简，沟通成本低、效率高。

  好吧，这么敷衍的回答，让谁看，谁又能看得懂？噗嗤，我还是秉承负责到底的君子之风，用购物网站的技术架构进化为例来讲述微服务!

  第一阶段。早年间，小红在某宝开了个网店，这个网店的功能超级简单。网店端主要有注册登录功能、商品展示、下单;管理后台有用户管理、商品管理、订单管理功能。为了管理后台的安全性考虑，网店端没有和管理后台做在一起。总体架构如下图。

 

  经过简单的部署之后，小红找了家云服务厂商进行数据托管，使用起来非常方便。

  第二阶段。随着移动购物的兴起，小程序、移动APP、wap端流量逐渐起来，营销促销手段逐渐丰富起来，小红知道，之前的网站部署并不能满足现在的需求了。时间紧迫，小红并没有规划整个系统架构，拍了拍脑袋，决定把促销管理和数据分析都放在管理后台里，小程序端和移动端另外搭建，架构如下。

 

  这个架构有很多不合理的地方，网页端、微信端、移动端重复代码，数据通过数据库共享，调用数据容易出错;网站搭建越来越臃肿。时间越长越限制越限制网店的发展，这个时候，小红决定必须做出改变。

  于是小红彻底改变了逻辑思维，决定以各项服务为主导来建设网店，比如以用户服务、商品服务、订单服务、促销服务、数据分析服务为主导，形成各种各样的微服务，微信、移动端、网站享用同一个代码，将网站进行了简化。架构如下：

 

  可是，这个架构还是有弊端，共用数据库造成从数据库提取另一个服务的数据现象，牵一发动全身，还是不够方便。

  于是，简化、简化、再简化，将服务与各自数据结合的框架，比如用户服务数据仓库、商品服务数据仓库、订单服务数据仓库等，这些服务、数据都可以调用，分工明确，至于弊端在这里不多讲。

 

  以上的这些用户服务之类的，就是微服务了。

  它们之间其实是独立部署、原子的、自治的业务组件，彼此之间通过消息中间件进行交互。

  DevOps

  DevOps是研发运维一体化，通过自动化流程使得软件过程更加快捷和可靠。它不是一个产品，而是一种新的团队工作方式、新的技术理念。

  还是那个说法，这么说太简单了吧，还有些敷衍。好吧，我好好掰扯掰扯。

  一般情况下，一个软件最终交付经历以下阶段：市场规划、产品规划、编码设计、编译构成、部署测试、发布上线、后期维护等。早期在人员少得情况下，为了能够及时交付，软件走一遍流程基本上交付了。这是早期的瀑布式开发。

  之后，随着人员的扩张，这时团队里有了产品经理、开发人员、测试人员、运维人员的划分。这些人员负责研发、测试、上线发布、运维等，整个过程不断开发、测试、再开发、再测试，验证无误之后部署上线。这就是敏捷开发。

  时间长了之后，敏捷开发也有弊端，总是在自己开发、测试，延长了产品开发周期。为了规避这个弊端，DevOps来了，它将整体的开发需求变成小的需求点，每完成一个小需求点就上线部署，快速验证，捕捉用户。

 

  Wait，我还是用“酒店更新菜品”为例，简单说说吧!

  瀑布式开发：我们要更新菜品，我们市场调研、设计菜品、品尝菜品、上线菜品。好了，我们更新完了。

  敏捷开发：我们要更新菜品，我们市场调研、设计菜品、品尝菜品，这个菜不太好吃，再设计菜品、品尝菜品，咦另一个菜不好吃，再再设计菜品、品尝菜品，直到没有问题，上线菜品。

  DevOps：我们要更新菜品，我们市场调研、设计一道菜、品尝菜品、上线这道菜，然后我们设计另一道菜、品尝菜品、上线这道菜。把每道菜当成小需求点，最终完成大需求点。

  持续交付

  持续交付就是一直在交付，敏捷开发和DevOps要求随时都有一个合适的版本部署在生产环节上，频繁发布、快速部署、快速验证，所以必须要持续交付。

 

  以前的交付太慢了，现在云原生要求持续交付，那么如何频繁发布、快速部署、快速验证？这里提出了两个方法论：灰度发布、蓝绿发布。灰度发布很好理解，就是在新需求开发完成之后，让一部分用户继续使用老版本，一部分使用新版本，如果用户对新版本没意见，再迁移到新版本来。

 

  蓝绿发布实际上将应用从逻辑上分为A、B两组，版本升级时，将A版本从负载均衡器里删除，进行新版本部署，同时B组提供服务。当A组升级完毕之后，按照同样的逻辑升级B组。

  我们简单理解一下蓝绿发布，某家小饭店想让仅有的两名厨师进修，同时不想影响饭店生意，于是饭店想了一个方法，先让厨师A进修，厨师B在饭店炒菜，厨师A进修完毕，厨师B进修，按照这个方法，饭店生意没有影响，饭店的厨艺还得到提升。

  容器化

  容器技术的定义就是一个单独的应用程序进程、运行资源的高度隔离。

  第一阶段。最早的时候，应用全部运行在电脑等物理机上，这就导致资源分配不均匀，出现个别应用占用内存、计算资源过大的情况，其他应用难以运转。

  第二阶段。中期的时候，虚拟机出现了。虚拟机是在我们操作系统上虚拟出来的电脑，在虚拟机上可以安装、运行各种各样的软件，一台物理机可以运行多个虚拟机，提高了资源利用率，不过虚拟机还是在占用物理机CPU、内存、硬盘等硬件资源，整体显得笨拙。

 

  第三阶段。云计算时代，要求快速开发迭代、持续交付等，虚拟机这种不能保证应用环境都一致，因此，容器化被提上议程，也就是通过虚拟的软件资源，把网络、存储分成虚拟容器，应用在这些容器中运行。

  可以说微服务、DevOps、持续交付、容器化是云原生四大核心要素了，满足这些，才能成为云原生，就如同云原生的阳光、水、空气一样。

  “我只问你微服务、DevOps、持续交付、容器化，你有必要说这么多吗?”

  好吧......

 

  没想到头悬梁锥刺股之后，依旧逃不脱“承包一个月家务”的厄运。