云原生实践系列：概述

云原生是个被炒烂了的话题，但人与亦云并非笔者的风格，既然要写自然会写出个性，写得与众不同。本系列不会从宏观上泛泛而谈，而是从架构细节切入，聊聊一下什么是可落地的云原生。

笔者有一个观点： 业务需求复杂度的提升必然导致技术复杂度的提升 。大家可能所看到的某一框架说可以简化开发，那只不过是把复杂度做了转移，要么转移给了框架自身，框架变得很重，要么转移给了运维侧，运维变得复杂。同理，云原生架构之所以可以简化开发只不过是把原来开发阶段要关注的内容转移到了运维阶段，但由于运维比开发更聚焦，更容易做标准化，所以云原生架构会直接体现出生产成本的降低，这是云原生最大的优势。

大家都知道服务架构始于单体架构，笔者觉得那是架构的“田园时代”，一切都是那么简单、直接。但随着业务复杂度的提升SOA应运而生，SOA可谓是架构的“春秋战国时代”，那时期涌现出了大量的技术、框架，英雄辈出，这也是架构从无序走向规范的时期。再后来就是我们熟知的微服务架构，微服务架构是SOA的衍生，解决了传统SOA划分粒度过粗、调用过于中心化等问题，这是架构的“摩登时代”，服务架构从未如此地被重视，但随之而来的便是技术复杂度的直线攀升。

人们不禁怀念那个“琴瑟在御，莫不静好”的单体架构，而此时云原生逐渐走俏，敏锐的人发现基于云原生的 Service Mesh 好像可以降低微服务的技术门槛，于是 Service Mesh 被看做是下一代的微服务架构，它被寄希望于将服务架构从高度工程化、集约化的摩登时代拉回到简单、个性的田园时代。在 Service Mesh 下只要符合规范的通讯协议就可以使用任何的语言任何的框架开发，Service Mesh 平台会确保无差别的对待各类接入技术。

服务框架发展了这么多年有些人按耐不住了，寻思着有没有更好的，比单体架构更简单但能力更完备的架构，单体架构再怎么简单还是得建项目建脚手架发布部署并且无法很好地复用已有的能力，所以就冒出了 Serverless 架构，后者以 FaaS/BaaS 为基础，函数化编程将后端能力标准化、API化，最终提供一个开箱即用的项目开发能力。这也是笔者认为服务架构未来的方向。Serverless 是个好东西，但目前它极不成熟，如厂商绑定，换一个厂商脱一层皮，再如对实时处理不友好，函数启动耗时高，这些都是 Serverless 亟待解决的问题。

本系列讲的是云原生，跑题了吗？不然，无论是 Service Mesh 还是 Serverless ，它们的技术基础都是云原生，都是云原生架构下的产物。

上一节我们简单回顾了服务架构的发展及展望，现在我们再具象些，聊一聊服务框架：如何评价一个服务框架的好差？ 这自然有很多因素，但如果说最关键的因素那一定是“易用”，框架的开发人员日常接触最多的东西，一个易用性强的框架是生产力的基础，是俘获开发人员“芳心”的关键。

易用性的具体表现有三点：

以上三点笔者会结合云原生环境在后续的文章中进一步阐述。

有了服务框架后我们还需要DevOps流程及工具链的支撑，DevOps与服务框架相辅相成，共同形成了研发流程的闭环。

市场上做DevOps服务的厂商非常多，但能力也参差不齐。我们需要怎样的DevOps？笔者觉得有以下几点：

这三点笔者也会结合云原生环境在后续的文章中进一步阐述。

最后我们会再探讨下研发管控流程在云原生环境下的重点要点，云原生是为了更好地标准化，实现更高的经济效益，这需要研发管控也做出相应的调整，我们希望看到的是一个敏捷的、规范的，研发、管理人见人爱的流程制度。

我们看到了AI、看到了大数据、看到了区块链技术的如日中天，但这些技术框架后背后要么基于云原生架构，要么在向云原生迁移的路上，可以说云原生是立足当下通向未来的基础架构，任何研发人员都应该加以关注、学习。

To be continued.