云原生（Cloud Native）产品之路

从2015 年，Pivotal公司的Matt Stine提出Cloud Native这一概念以来，Cloud Native的热度一路攀升，在云计算已经广泛被接受的今天，确实Cloud Native是一种必然的选择。

   （谷歌指数显示的搜索，不过国内百度和360指数都未收录，说明这还是行业内比较热的词）

华为公司为了支撑公司“全云化战略”的落地，曾经提出产品开发要坚定不移地推进全云化战略，用Cloud Native的理念、架构和方法开发产品，用一个架构适应公有云、私有云、混合云场景，快速、灵活、规模、可靠、高效地满足客户需求。

也就是产品的Cloud Native是要支撑业务战略的，这也是我将这篇文章作为产品的开篇的原因：不要盲目的做Cloud Native产品，必须从业务战略出发。

鼻祖Matt Stine在《迁移到云原生应用架构》中提出需要云原生的原因：快速、安全、弹性拓展和移动应用与客户端多样性。华为是在2016年分析师大会提出的全云化战略，华为轮值CEO徐直军提到的原话是：“如果说2015年分析师大会上，我们提出的ROADS体验模型，定义了什么叫好的用户体验，那么今年的全面云化战略，就是要解决如何实现ROADS体验。ROADS体验需要业务、网络、运营系统来共同支持才能实现。”用户的消费体验是在变化的，所以面向用户的企业必须改变自己提供消费内容的方式。华为作为供应商，要给这些企业提供可以支撑其应对用户体验变化的方案，才能继续发展。但是，并不是什么产品都要Cloud Native。

所以，第一个判断要不要Cloud Native，或者Cloud Native到什么程度，一定是从一开始面向的市场的特点、业务战略出发分析清楚后，再确定的。

那么就运营商而言，所谓的Cloud Native应该是什么？我觉得是云的本质——资源高效利用。云化之后，资源可以按需调度。这个角度来说，就不要僵化Cloud Native了。在设计产品的时候一定要想明白这一点。

以移动支付产品来举例。首先要清楚的是移动支付这个市场的特点是什么？本质上是消费者的支付手段，那么其特点就是由消费者支付行为决定的。这种行为的特点有三：1）灵活性，购买行为受促销等市场活动影响大，支付行为也随之变化，因此要能快速试错，更重要的是能快速赶上对手的新打法，并且造成很多突然的大流量冲击；2）行业多样性，每个行业的支付玩法都不一样；3）敏感性，基本不能忍受停业务，更不能允许出现安全问题。基于这三个特点，移动支付产品就需要能快速响应运营团队的需求，也要能确保过程中不出现业务不可用的情况，同时要足够开放。尤其是为了满足开放，移动支付产品只能朝着原子化方向发展，否则产品就越做越厚，API多如毛牛，我见到一些产品人经常以一个产品的API数量为荣，其实不然，API数量做到极致的少才显得更有力量。

其次，业务定位是什么？面向拥有支付牌照的公司提供平台加生态服务，对于部分客户开展合作运营。这样的定位下，这个市场的特点就自然传导到了我们的产品，所以Cloud Native是必然选择。假如移动支付产品只定位于PaaS，我认为只是云而已，而非必须Cloud Native。

我认为Cloud Native应该从以下五方面评估与考虑：文化、人才、组织、架构、平台。

一、为什么先谈文化？

与文章一开头先讲业务本身面临的背景是一样的，对于一个要做Cloud Native产品的组织而言，首先应该具备的就是文化的认同。这个文化是什么？精益、敏捷的文化。《精益思想》这本书对精益的定义是：“精益思想是关于如何有效组织人类活动的一个新的思维方法，它的目标是消除浪费，更多地交付对个人和社会有用的价值“。其本质的精神归属是减少浪费。粗浅一点理解如何减少浪费，就是两点：减少重复的事，减少不必要的事。怎么减少重复的事呢？第一，活动不要重复，第二，重复的活动自动化。怎么减少不必要的事？尽早让市场看到，保证做出来的东西是市场要的，而非想象出来的。中国人是讲究节俭的，但是一富有起来就不顾浪费了，这和西方人的认知有所区别。这是为什么要先谈文化的根本原因。日本人、西方人追求精益的过程相继有了精益生产、DevOps、Scrum、持续交付、持续集成、持续部署、精益创业等一轮一轮的演进，其背后是这种哲学思想的高度认可。如果我们一开始就去套概念和框架，那么终究是跟随。

二、人才与组织

这个组织中的人都应该是认可这种文化价值观的，组织的形式就应该突破科学管理思维的限制。我在《50%的工作都将被人工智能取代？9本书找准未来定位！》一文中已有阐述，感兴趣的可以阅读。

三、架构与平台

架构最重要的就是实现最大化解耦，以及适应当前云计算背景的平台基础模式，概括起来“7+1”模式：

“1”——（微）服务架构：系统由（微）服务构成，（微）服务之间只能通过接口进行交互，（微）服务独立开发、测试、发布、部署、升级。

“7”——云基础设施与平台服务、弹性伸缩、分布式、高可用、自动化运维、自服务、多租户。

在这里要强调的是，Cloud Native产品所依赖的平台，工欲善其事必先利其器，这一点是产品团队应该坚持的理念，凡是可以依靠工具的就应该使用工具，凡是重复的都应该自动化。

华为的DevCloud就是一站式的DevOps平台，加上ServiceStage提供的微服务架构平台，基本上可以解决所有需要。

总结：Cloud Native产品之路的起点必须是产品团队对业务的深度理解，并且覆盖到团队每一个人。第二，将Cloud Native文化融入到业务与产品团队中。第三，团队的组织形式包括考核方式与这种文化匹配，简单的说，这个产品团队不应该有明确的职能划分。最后，选择合适的架构与平台，这个选择中做权衡时的原则是前三点。针对以上三部分，后续都会有专门的阐述。

*附录：

1.《迁移到云原生应用架构》：https://jimmysong.io/migrating-to-cloud-native-application-architectures/