共计 1960 个字符，预计需要花费 5 分钟才能阅读完成。
简介： 云原生这个概念曾经越来越深入人心，但对“云原生到底是什么？”这个问题，依然是各种各样的解读，最近对云原生具体是什么有了点感触，于是写下来分享和探讨下。
本文转载自公众号：HelloJava。
云原生这个概念曾经越来越深入人心，但对“云原生到底是什么？”这个问题，依然是各种各样的解读，最近对云原生具体是什么有了点感触，于是写下来分享和探讨下。
我当初认为云原生其实是让泛滥的公司，通过基于云的产品迅速取得在构建一个当初这个时代的利用（是不是有点像 AWS 始终讲的 Modern Applications）所必须的各种根底能力（如：极强的规模伸缩性、极高的可用性、极低的翻新 / 经营老本、大数据的剖析 / 经营能力等等），而不须要像以前的很多公司，为了具备这些能力，投入微小，或者用另外一句话说： 云原生就是业余的根底能力普惠化，顺手可得 。
当今时代的利用和多年前的利用面临的情况差异太大，这个差别和当今业务面临的强烈竞争和玩法有很大的关系，我以前始终感觉像阿里在倒退过程中积攒的很多能力，里面很少有公司会须要，就像当年百亿、千亿美金的公司是如许难才呈现，但当初看来则齐全不一样，所以这也奠定了当今时代的利用在技术层面能力的要求也远不一样，简略说几个点：
- 对可用性的要求远高于以前的利用：当初的利用通常一上线对可用性要求就曾经不低了，因为一旦出问题就很容易把用户送给竞对；
- 对伸缩性的能力要求也远比以前高，次要体现在两个方面：一是团队规模，当初的业务公司很容易迅速倒退到百人以上，而百人以上的研发效率如何放弃尽量不降落，这对系统的伸缩能力有着很高的要求；二是用户规模，当初泛滥业务的用户规模能够很快地冲破百万、千万规模，这就要求零碎必须能依据用户规模疾速地伸缩；
- 翻新和经营的老本必须低：业务竞争无比强烈，快是要害，所以怎么在不须要太大投入的状况下疾速上线各种业务，是无比重要的；另一个方面就是经营的老本，这个是和当初利用的用户规模、强烈竞争密切相关的；
- 大数据的玩法：当初的很多业务对获客、举荐、搜寻等的大数据化要求还是相当高的。
阿里是一家在本身倒退过程中，逐渐碰到上述的挑战（当年的竞争环境根本还不会要求一个业务上来就把各种能力具备好），但以前也没有云可用，所以在倒退过程中一直积攒各种能力，当初通过开源、云商业化对外输入这些能力，使得即便到了当初这样的竞争环境下，各种有业务翻新想法的同学们，还是能够像当年一样疾速上线业务，而不是要先投入巨多力量、破费巨多工夫把须要的根底能力打磨进去。
我本人并没有齐全经验阿里的倒退过程，接下来次要还是简略说下我本人经验的一些。
- 在 2007 年，淘宝在根底能力上面临的最大问题是伸缩性，两个景象过后都呈现了：用户数量大量减少，加机器曾经根本要加到瓶颈了；研发人员大量增长，研发效率下滑非常明显。在这个阶段，淘宝做了一轮十分重要的架构革新，磨难出了例如服务框架、消息中间件、分库分表计划、分布式文件系统、分布式缓存等根底技术产品，联合业务架构的从新设计，很好地解决掉了伸缩性的问题。
- 在 2009 年，淘宝面临了可用性问题，常常出各种故障，于是开始积攒各种监控、疾速复原、tracing、零碎设计里如非关键门路异步化等技能。可用性这块的投入始终在继续，到起初为解决 双 11 这种非凡状况的可用性、确定性诉求而发明的全链路压测；通过同城双活、异地多活的多机房体系构建的强容灾能力以及疾速恢复能力等；以及在线下场景退出起初面临的不一样的可用性计划等。各种场景的高可用计划的积攒，也使得业务的可用性越来越有保障。
- 2011 年左右，阿里开始感觉将来在资源投入上的经营老本可能会很夸大，于是在 2011 年开始通过容器化来晋升机器应用效率、继续进行老本优化，起初又继续通过云资源弹性来解决 双 11 这类型的短时顶峰的老本投入问题，通过在线离线混部解决大数据机器投入越来越大、在线机器集群利用率不高产生节约的问题，通过多年致力，使得业务在高速增长的状况下，机器资源投入上的经营老本还是绝对可控的。
如上文所讲，阿里是依附微小的人力投入、场景打磨和多年的继续投入才逐步造成了齐备的能力。而当初的业务，则能够用云原生的形式构建，使本身一上来就具备这些能力，至多可能让本人在现在强烈且要求更高的业务竞争环境中，不会在这些根底能力上拖后腿，以此能够花更多的精力、工夫、资源在真正的业务翻新上。这样具象化的云原生对整个社会的翻新还是相当有价值的。
版权申明： 本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。
