云原生时代, 选择.NET Core
在容器、Kubernetes、DevOps，以及微服务等技术的推动下，2020年云原生势不可挡。 .NET Core 也非常契合 云原生对应用运行时的不同需求，.NET Core和kubernetes 同年诞生发展， 2018年kubernetes 已经奠定了在容器编排领域的王者地位，2019年越来越多的企业选择基于云原生的技术或管理方法，把业务生于云或迁移到云平台，从而享受云的高效和持续的服务能力。几年前火热的Spring Cloud面临Kubernetes的革命，如今.NET Core在云原生方面完成的蜕变：
体积更小：对于微服务分布式架构而言，更小的体积意味着更少的下载带宽，更快的分发下载速度，.NET Core 的镜像体积都很小，alpine的镜像更小，带上应用程序通常80M。
启动速度更快：对于传统单体应用，启动速度与运行效率相比不是一个关键的指标。原因是，这些应用重启和发布频率相对较低。然而对于需要快速迭代、水平扩展的微服务应用而言，更快的的启动速度就意味着更高的交付效率，和更加快速的回滚。尤其当你需要发布一个有数百个副本的应用时，缓慢的启动速度就是时间杀手。对于Serverless 应用而言，端到端的冷启动速度则更为关键，即使底层容器技术可以实现百毫秒资源就绪，如果应用无法在 500ms 内完成启动，用户就会感知到访问延迟。这里我拿AWS Lambda来举例，因为各大云厂商都是以AWS是模仿的目标，AWS Lambda中可用的所有语言都是高级的，而不是像Assembler，C / C ++或Objective C那样。从脚本语言到JavaScript和Python，再到像Java和C＃到Go这样被编译为二进制文件的托管运行时的语言，所有语言都是他们有自己的长处。在基准测试中，最重要的.NET Core是 冠军，具体参看https://react-etc.net/entry/aws-lambda-benchmarks-node-js-python-java-c-go-dotnet-core
占用资源更少：运行时更低的资源占用，意味着更高的部署密度和更低的计算成本。.NET Core的 CLR启动速度非常快，降低启动时资源消耗，可以减少资源争抢，更好保障其他应用 SLA。
支持水平扩展：.NET Core 默认更好的支持Docker资源限制，官方团队也在努力让.NET Core成为真正的容器运行时，使其在低内存环境中具有容器感知功能并高效运行。随着内存成本的下降和虚拟化的流行，大内存配比已经成为趋势。所以我们一般是采用水平扩展的方式，同时部署多个应用副本，在一个计算节点中可能运行一个应用的多个副本来提升资源利用率。
上面说了.NET Core在云原生方面所完成的蜕变，很多人可能会以Java生态丰富来说明Java的种种优势，所以这里我想一起来看看十年前李彦宏、马化腾和马云对云计算的评价：
站在现在的位置往回看，七年前李彦宏、马化腾的观点确实是挺幼稚的。一个犯了商业判断上的错误，认为用公有云（虽然这个会上谈的是云计算，但指的是AWS、阿里云这样的公有云）方式赚点钱会比较累，商业价值不大；一个犯了技术判断上的错误， 认为要大规模地，像水和电那样提供计算资源，技术上要做到没这么快，需要时间。 但是公有云此后的高速发展，即证明了自身的巨大的商业价值，也证明了现有技术的能力和潜力。
经过8年的发展，公有云已经不仅仅像李彦宏说的，支撑一些互联网应用这么简单，而是巨大的，充满希望和想象的平台。现在我们所说的云原生已经不局限于AWS，阿里云，腾讯云这样的公有云，也不是仅仅局限于私有云，而是我们在开始设计应用的时候就考虑到应用将来是运行在云环境里面的，要充分利用云资源的优点。但从不同的角度，你能够看到这个平台不一样的威力。
马化腾说云计算难做， 短期内很难做好的观点，虽说太悲观， 但也是说出了广大后台程序猿的心声。 从个人研发的经历而言， 我们有两种完全不一样的开发，一种是单机软件的开发，另一种是分布式后台开发。单机软件开发， 更多的是专注于业务本身， 计算和存储资源的获取很轻松地搞定、模块间通信无比简洁美好根本不用操什么心，见过大量的.NET程序员开发的都是这种单机软件开发，他们的系统做个集群都难；而分布式后台开发，在计算资源、存储资源或业务逻辑单元在做了 “分” 这个操作后， 就变得无比揪心，你会发现做后台的业务简单，但做一个稳定高性能的架构难，做一个能够扛住海量用户和请求，还能够动态生长以应对业务变化需求的后台更是难上加难。
海量后台服务研发方法论方面在这个世界上也有腾讯海量服务之道和Google 的另一套后台哲学：
腾讯对后台开发的理解是这样的：放弃建立一个统一模型，按照这个模型去套各种业务，就能够为业务建立一个完善的架构，而且这个架构能够适应业务后续的发展。 而是用动态生长的眼光，以小步快跑的方式，用柔性的手段去处理和和各种分布式问题周旋，最终成功支撑业务向前发展。
Google的另一套后台哲学：根据自身业务抽象出几大基础后台系统（比如GFS、BigTable、Spanner、Borg、Tensorflow 等）， 支撑业务的开发，从而业务可以专注于自身逻辑， 不需要关注底层分布式细节，这个对技术人要求就非常高，微软也是这样的一个套路。由于我没有在Google呆过，对Google不太了解，只能从Google 在10几年的引领技术潮流的技术做个概括。这里说说kubernetes吧，早在2003年google 就在运行容器，当时的容器调度系统叫做Borg，到后面的Omega，向Linux内核贡献 CGroup【CGroup全称Linux Control Group， 是Linux内核的一个功能，用来限制，控制与分离一个进程组群的资源（如CPU、内存、磁盘输入输出等）。这个项目最早是由Google的工程师在2006年发起（主要是Paul Menage和Rohit Seth），最早的名称为进程容器（process containers）。在2007年时，因为在Linux内核中，容器（container）这个名词太过广泛，为避免混乱，被重命名为cgroup，并且被合并到2.6.24版的内核中】，2014年开源kubernetes项目，这十多年来google一直在容器中运行所有产品。具体参见《Borg、Omega和Kubernetes：谷歌十几年来从这三个容器管理系统中得到的经验教训》
这两套方法论，目标相同，但是思路相反。个人认为， 能够解决问题，帮助业务往前走的发展都是好方法，除此之外， 并没有一个标准能够用来评判哪个好哪个不好。 两种典型的后台价值观，分别支撑起排名前几的两家互联网公司，就足以说明其成功之处。但是从中我们可以看出， 做后台特别是海量服务的后台之难。 由此不难理解马化腾所说， 需要等到阿凡达的时代，像水和电一样的云计算才能够实现。
时代的潮流滚滚向前，我现在来到了云原生时代，在容器化的世界里，Kubernetes是环境的管理和部署引擎。使用Kubernetes的最基本功能，用户就可以轻松地在物理硬件或者虚拟机上调度并且运行应用程序。Kubernetes的更多高级用法让开发人员可以彻底摆脱主机为中心的世界，而进入容器为中心的环境里。
应用程序是如今大多数业务的生命线。公司需要快速的部署和高质量的应用程序。这些需求正是开发人员转向容器的原因。随着容器的发展，Kubernetes平台有很多的可能性，但是规模大了的话它也很难管理。云原生时代一定要拥抱，这是云原生时代给予.NET Core的机会，我希望大家能够抓住。
说到这里，这里特别要和你分享一件事情是2018年的11月我有幸参观访问了肖伟宇所在的公司校宝在线，当时我也是刚从腾讯离职从事.NET Core的咨询服务工作，当时他们正是在进行.NET向.NET Core迁移的关键时期，他们同时处在阿里巴巴大本营的杭州（），而且当时阿里巴巴已经投资了校宝在线，坊间一直流传着这么一个梗：被阿里巴巴投资的公司都转向了Java，可想而知，校宝在线作为杭州地区最大的一家.NET技术公司 的兄弟们面临多大的压力，在经过了一年多时间的探索，肖伟宇作为校宝在线的架构师带领.NET兄弟成功走向.NET Core云原生的道路，这是非常值得分享的一件事情，而且难能可贵的是肖伟宇把这个探索道路上的艰难险阻总结提炼成这样一门视频课程。这里我非常推荐大家购买肖伟宇结合自己的经验精心提炼的视频课程。