当今软件发展的现状很是适合 Cloud Native 环境

当今软件行业正发生着巨变。自上世纪50年代计算机诞生以来，软件从最初的手工做坊式的交付方式，逐渐演变成为了职业化开发、团队化开发，进而定制了软件件行业的相关规范，造成了软件产业。

今天，不管是大型企业仍是我的开发者，都或多或少采用了云的方式来开发、部署应用。无论是私有云，仍是公有云，都终将给整个软件产业带来的革命。我的计算机或者以手机为表明的智能设备已经走进寻常百姓家了。每一个人几乎都拥有手机，手机不只仅是通讯工具，还能发语音、看视频、玩游戏，让人与人之间的联系变得更加紧密。智能手环随时监控你的身体情况，并根据你天天的运动量、身体指标来给你提供合理的饮食运动建议。出门逛街甚至不须要带钱包了，吃饭购物搭车时使用手机就能够支付费用，多么方便快捷。智能家居系统更是你生活上的“管家”，何时该睡觉了，智能家居系统就自动拉上窗帘，关灯；早上起床了，智能家居系统会自动拉开窗帘，并播放动人的音乐，让你能够愉快地享受新的一天的来临；你不再用担忧家里的安全状况，智能家居系统会帮你监控一切，有异常状况时会及时发送通知到你的手机，让你第一时间掌握家里的情况。将来，每一个人都可以拥有《Iron Man》（钢铁侠）中所描述的智能管家 Jarvis。而这一切，都离不开背后那个神秘的巨人——分布式系统。正是那些看不见的分布式系统，天天处理着数以亿计的计算，提供可靠而稳定的服务。这些系统每每是以 Cloud Native 方式来部署、运维的。

软件需求的发展

早期的软件，大多数是由使用该软件的我的或机构研制的，因此软件每每带有很是强烈的我的色彩。早期的软件开发也没有什么系统的方法论能够遵循，彻底是“我的英雄主义”，也不存在所谓的软件设计，纯粹就是某我的的头脑中思想的表达。并且，当时的软件每每是围绕硬件的需求来定制化开发的，有什么样的硬件就有什么样的软件。因此，软件缺少通用性。同时，因为软件开发过程不须要与他人协做，因此，软件除了源代码外，每每没有软件设计、使用说明书等文档。这样，就形成了软件行业缺少经验的传承。

从60年代中期到70年代中期是计算机系统发展的第二个时期，在这一时期软件开始被看成一种产品被普遍使用。所谓产品，就是能够提供给不一样的人使用，从而提升了软件的重用率，下降了软件开发的成本。好比，之前，一套软件，只能专门提供给某我的使用。如今，同一套软件能够批量的卖给不一样的人，显然，分摊到相同软件上的开发成本而言，卖的越多，成本天然就越低。这个时期，出现了相似“软件做坊”的专职替别人的开发软件的团体。虽然是团体协做，但软件开发的方法基本上仍然沿用早期的个体化软件开发方式，这样致使的问题是，软件的数量急剧膨胀，软件需求日趋复杂，软件的维护难度也就愈来愈大，开发成本变得愈来愈高了，从而致使软件项目频频遭遇失败。这就演变成了“软件危机”。

“软件危机”迫令人们开始思考软件的开发方式，使得人们开始对软件及其特性进行了更加深刻的研究，人们对待软件的观念也在发生悄然的改变。在早期，因为计算机的数量不多，只有少数军方或者科研机构才有机会接触到计算机，这就让大多数人认为，软件开发人员都是稀少且优秀的（一开始确实也是如此，毕竟计算机最初制做者都是数学界的天才）。因为，软件开发的技能，只能被少数人所掌握，因此大多数人对于“什么是好的软件”缺少共识。实际上，早期那些被认为是优秀的程序经常很难被别人看懂，里面充斥着各类程序技巧。加之，当时的硬件资源比较紧缺，迫使开发人员在编程时，每每须要考虑更少的占用机子资源，从而会采用不易阅读的“精简”方式来开发，这更加加剧了软件的个性化。而如今人们广泛认为，优秀的程序除了功能正确，性能优良以外，还应该更加让人容易看懂、容易使用、容易修改和扩充。这就是软件可维护性的要求。

1968年 NATO 会议上首次提出“软件危机”(Software Crisis)这个名词，同时，提出了指望经过“软件工程（Sotfwrae Engineeirng）”来解决“软件危机”。“软件工程”的目的，就是要把软件开发从“艺术”和“个体行为”向“工程”和“群体协同工做”进行转化，从而解决“软件危机”包含两方面问题：

• 如何开发软件，以知足不断增加，日趋复杂的需求；
• 如何维护数量不断膨胀的软件产品。

事实证实，在软件的可行性分析方面，事先对软件的进行可行性分析，能够有效的规避软件失败的风险，提升软件的开发的成功率。

在需求方面，软件行业的规范是，须要制定相应的软件规格说明书、软件需求说明书，从而让开发工做有了依据，划清了开发边界，并在必定程度上减小了“需求蔓延”的状况的发生。

在架构设计方面，需制定软件架构说明书，划分了系统之间的界限，约定了系统间的通讯接口，并将系统分为多个模块。这样，更容易将任务分解，从而下降系统的复杂性。

今天，制定软件需求的方式愈来愈多样化了。客户与系统分析师也许只是通过简单的口头讨论，制定了粗略的协议，就安排开发工程师进行原型设计了。开发工程师开发一个微服务，并部署到云容器中，从而能够实现软件的交付。甚至，能够不用编写任何写后台代码，直接使用云服务供应商所提供的 API，使应用快速推向市场。客户在使用完这个应用时，立刻就能将本身体验反馈到开发团队，使开发团队可以快速的响应客户的需求变化，并促使软件进行升级。

经过敏捷的方式，最终软件造成了“开发——测试——部署——反馈”的良性循环，软件产品也获得了进化。而这整个过程，都比传统的需求获取的方式将更加的迅捷。

开发方式的巨变

早些年，瀑布模型仍是标准的软件开发模型。瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，而且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工做结果，实施完成所需的工做内容。当前活动的工做结果须要进行验证，如验证经过，则该结果做为下一项活动的输入，继续进行下一项活动，不然返回修改。

瀑布模型优势是严格遵循预先计划的步骤顺序进行，一切循序渐进，整个过程比较严谨。同时，瀑布模型强调文档的做用，并要求每一个阶段都要仔细验证文档的内容。可是，这种模型的线性过程太理想化，主要存在如下几个方面的问题在：

• 各个阶段的划分彻底固定，阶段之间产生大量的文档，极大地增长了工做量；
• 因为开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增长了开发的风险；
• 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果；
• 各个软件生命周期衔接花费时间较长，团队人员交流成本大。

瀑布式方法在需求不明而且在项目进行过程当中可能变化的状况下基本是不可行的，因此瀑布式方法很是适合需求明确的软件开发。但在现在，时间就是金钱，如何快速抢占市场，是每一个互联网企业须要考虑的第一要素。因此，快速迭代、频繁发布的原型开发、敏捷开发方式，被愈来愈多的互联网企业所采用。甚至，不少传统企业，也在逐步向敏捷的“短平快”的开发方式靠拢。毕竟，谁愿意等待呢？

客户将需求告诉了你，固然是越快但愿获得反馈越好，那么，最快的方式莫过于在原有系统的基础上，搭建一个原型提供给客户做为参考。客户拿到原型以后，确定会反馈他的意见，是好或者坏的方面都会有。这样，开发人员就能根据客户的反馈，来对原型进行快速更改，快速发布新的版本，从而实现了良好的反馈闭环。

今天，Cloud Native 的开发方式正在流行。Cloud Native 是以云架构为优先的应用开发模式。Cloud Native 利于最大化整合现有的云计算所提供的资源，同时也最大化节约了项目启动的成本。

云是大势所趋

目前，愈来愈多的企业已经在大规模开始拥抱云，在云环境开发应用、部署应用、发布应用。将来，愈来愈多的开发者也将采用 Cloud Native 来开发应用。

那么，为何咱们须要使用 Cloud Native？

• 云计算的第一个浪潮是关于成本节约和业务敏捷性，尤为是云计算的基础设施更加廉价。随着云计算的不断发展，企业开始采用基础架构即服务（IaaS）和平台即服务（PaaS）服务，并利用它们构建利用云的弹性和可伸缩性的应用程序，同时也可以知足云环境下的容错性。
• 不少企业倾向于使用微服务架构来开发应用。微服务开发快速，职责单一，可以更快速的被客户所采纳。同时，这些应用可以经过快速迭代的方式，获得进化，赢得客户的承认。Cloud Native 能够打通微服务开发、测试、部署、发布的整个流程环节。
• 云供应商为迎合市场，提供了知足各类场景方案的 API，例如用于定位的 Google Maps，用于社交协做的认证平台等。将全部这些 API 与企业业务的特性和功能混合在一块儿，可让他们为客户构建独特的方案。全部这些整合都在 API 层面进行。这意味着，无论是移动应用仍是传统的桌面应用都能无缝集成。因此，采用 Cloud Native 所开发的应用都且具有极强的可扩展性。
• 软件不可能不出故障。传统的企业级开发方式，须要有专职人员来对企业应用进行监控与维护。而在 Cloud Native 架构下，底层的服务或者是 API 都由将部署到云中，等价于将繁重的运维工做转移给了云平台供应商。这意味着客户应用将获得更加专业的看护，同时，也节省了运维成本。

那么如何来实现 Cloud Native 呢？其实这是一个很是大的话题，好比，做为开发者，你须要了解目前市面上流行的云供应商，了解微服务、SOA，了解 HTTP 和 REST，了解领域驱动设计（DDD），了解CI\CD和TDD，了解两个披萨，了解分布式的经常使用架构和模式等等。这里每同样都是一个庞大的课题，还好目前市面上已经有了一些资料可供学习，好比《Cloud Native 分布式架构原理与实践》，能够很是全面的指导开发者轻松入门 Cloud Native。

参考引用

• 原文同步至：https://waylau.com/the-way-to-cloud-native/
• Cloud Native 案例大全
• 简述 Microservices（微服务）
• Spring Boot 企业级应用开发实战
• Spring Cloud 微服务架构开发实战
• Cloud Native 分布式架构原理与实践
• 分布式系统经常使用技术及案例分析