如何看待看待字节跳动推出火山引擎云服务？将会给用户带来哪里价值？ 第1页

我有一个引以为豪的成就，那就是一周写了570多页的需求文档，大多数人估计没见过将近300多张A4纸的文档是什么概念，我只能告诉你，你承受不住。

具体的项目细节不能说，因为涉及到保密条例，不过可以公开的是这是海军使用的软件。那一周每天晚上都加班都半夜，因为我是实习生，再加上又从事着感觉很神圣很酷的工作，所以精神很不错，绝对没有消极怠工。

但是，让我极为的头疼的是，一些平时根本不在意的问题在文档变大巨大后就凸显了出来，比如字体不一致，行间距不一致，表格形式千奇百怪，其实将很多份分散的需求文档整理在一起也就花了3，4天，但是后面的调整花了剩下的所有时间。

当时的企业属于国企，开发的模式还是传统的瀑布模式，项目需求是甲方几个子单位共同提的，会开了很多次，初期的文档改了N遍，改到最后我都快不认识了，特别是有些地方因为甲方成分太复杂，结果都是冲突的。就这样反正是把500多页的文档搞定了，打印出来直接按毕业论文的形式胶装了。

听去开会的同事反映说，他们是拖了俩拉杆箱去的，里面放了几十本需求文档，注意是“本”，开会的过程不表，总之很头痛。

这里我想说的就是传统的开发模式，在前期对于文档的需求简直是偏执狂，在改格式的时候问过主管，我们写这么多最后真的按这个做吗？他的回复是不一定，可能项目直接被砍掉也不是没可能。

然后我们就按这个文档开发了4个多月，之后我就结束实习回学校了，没过俩月主管跟我微信说，这个项目一共三个单位一起做，我们单位被砍掉了。

渐行渐远的传统开发模式

传统的开发模式中，往往需要花很多的时间和精力去写文档，功能要求》、《投标方案》、《需求分析》、《技术分析》、《系统分析》、《数据库文档》、《功能函数文档》等。

准则就是要把大纲和细节都在前期定下来，之后大家就可以全力开发软件了，但是实际上往往是事与愿违的。

就比如下图，最初的需求与最后的验收结果可能大相径庭。

这就是传统开发模式的弊端，缺乏灵活性，如果开始错了，只能是一错到底。

这也是现如今“敏捷开发”模式的最大优势，充满了灵活性，可以使开发周期更短，另外采用迭代的方式更好的适应快速变化 。如下图所示，核心就在迭代，每隔一段时间就需要重新走一遍流程。

但值得注意的是，并不是所有的项目都适合敏捷开发，而传统的瀑布方法就要被扫进故纸堆里了。两者各有优缺点，瀑布模型适合需求稳定的项目，而敏捷开发与需求快速变化的项目十分匹配。

因为移动互联网的飞速发展，基本上所有的行业要想在这个时代保持竞争力并赢得市场，敏捷开发更符合当前这个时代的发展需求, 它可以更好、更快、更简单、更有效的应对随时需要修改的需求。

无处不在的云计算

现在的项目开发太快了，快到今天有了一个想法，晚上可能就把原型做了出来，这一切得归功于云计算，基于云计算的开发就相当于你要装修的时候，云计算平台把一切都给你准备好了。如果自己想DIY，那么材料有，水电有，各种风格的装修风格和说明书一应俱全，你可以随时DIY。当然你要是这也不相干，直接瞬间给你按照选定风格的样板房给你装修，当然有些地方可能就没法改动了。

各种各样的云分别都是什么？

云计算的三大形态分别是公有云、私有云和混合云。三种类型具有不同的特点，如果拿汽车做例子的话，公有云就是从租车公司租车，可以按自己的需求租不同种类的车，时间也可以包天也可以包月，用多长时间就交多少钱，这种特别适合出差到别的城市或者旅游，那么租车就是非常合理的选择。

而私有云就是私家车，完全的专属于自己，不用担心租车公司是否上班或者不用担心还车时间，可以根据自己的需求进行改造，唯一的缺点就是买了之后车就是自己的负资产，如果使用量不高的话也是对于资源的浪费。

混合云就是上述两者的结合，既有公有云（租车），也有私有云（私家车），在平时情况可以用自己的私家车，但是如果临时的需求增加的话，那么就可以去租几辆车，既可以保证自己的安全性和隐私性，又具有很大程度的灵活性。

但在这里我要强调的一种更新的理念“云原生”，为什么说这是一种理念，因为它并没有一个确切的定义。根据一个共识较强的说法，

云原生（CloudNative）是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。

总之来说，符合云原生框架的应用程序的设计初衷就应该是基于云上，为了支持这一点，云原生包含了四个要素：微服务+容器+DevOps+持续交付，这四个要素的主要目标就是快速开发，快速上线，快速交付。

火山引擎的云原生架构

说到敏捷开发，字节跳动旗下的火山引擎推出的全栈云原生化架构，就是云原生的一个例子。其中包含了多个子模块，比如基础设施层、服务层和安全保障等。

作为一个云原生架构，四个要素自然不能缺席，那就是微服务、容器、DevOps和持续交付。

1 微服务 - Microservices

微服务既是一种架构，也是构建软件的方法。在微服务中，应用被拆分成最小的组件，彼此独立。不同于将所有组件内置于一个架构中的传统单体式应用构建方法，在微服务架构中，所有部分相互独立，通过合作来完成同一个任务。其中的每一个组件或流程都是一个微服务。这种软件开发方法强调细粒度、轻量化，力求在多个应用中共享相似的流程。

微服务就是力求把一个大型任务拆分成尽可能多的小部件，然后通过组合的形式构成大应用。而火山引擎开发的云原生架构提供的基础设施层就可以让开发人员尽可能少的考虑底层的服务，而是让开发人员更敏捷、专注地开发业务逻辑 。

2 容器 - container

容器技术能够对应用及其整个运行时环境（包括全部所需文件）一起进行打包或隔离。从而让您可以在不同环境（如开发、测试和生产等环境）之间轻松迁移应用，同时还可保留应用的全部功能。

容器是开发人员的福音，因为发明容器以前，保证开发环境一样就跟你要求所有人用0.5mm的铅笔一样，容器的作用就是不管在任何环境，都能保证环境是一模一样的，包括操作系统。

这个特性对于敏捷开发来说，可以不用担心不同团队之间因为环境不同而造成进度卡壳。

3 DevOps

DevOps就是Development（开发）和 Operations （运维）的组合，从字面上也很好理解，就是所有进程齐头并进，这也符合敏捷开发的理论。 DevOps 强调通过一系列手段来实现既快又稳的工作流程，使每个想法（比如一个新的软件功能，一个功能增强请求或者一个 bug 修复）在从开发到生产环境部署的整个流程中，都能不断地为用户带来价值。这种方式需要开发团队和运维团队密切交流、高效协作并且彼此体谅。

此外，DevOps 还要能够方便扩展，灵活部署。有了DevOps，需求最迫切的工作就能通过自助服务和自动化得到解决；通常在标准开发环境编写代码的开发人员也可与 IT 运维人员紧密合作，加速软件的构建、测试和发布，同时保障开发成果的稳定可靠。

4 持续交付

这就涉及到了基于云原生的开发工作了，从字节跳动的公开资料来看，他们已经建立了自己的 移动开发平台，代号： MARS，通过它来统一支撑上层各个业务应用的开发工作。如今大家在用的抖音、头条等APP都是基于MARS进行开发和迭代。当然持续交付的基础就来自于云原生的支持，微服务、容易和DevOps的协同工作造就了应用快速上线的结果。

总结：

敏捷开发是适应当今快速变化市场的进化结果，只有这样才能保持竞争力并赢得市场，它更符合当前这个时代的发展需求, 它可以更好、更快、更简单、更有效的应对随时需要修改的需求。 但敏捷开发同样离不开配套设施的建设，天生为敏捷开发适配的云原生架构就是一个越来越不可或缺的选择。