为什么需要云原生

现在有很多的IT应用方式都打着云原生的概念，哪究竟什么是云原生？为什么要用云原生的方式来使用IT应用？云原生有什么好处和坏处呢？

一、云原生的概念

跟上次本渣的那篇
中国的SaaS究竟是好做还是不好做呢
可知，从SaaS的继续演变。人们继续更加激进的手段来让IT信息化能支撑更大规模的应用（直播带货、双11网购、AI大模型…），还要使用起来更加敏捷、方便、低成本等。我们再次结合IT设备生产和IT人才过剩这一个时代特征，互联网厂商和开源社区不断地从不同方向和层次去解决这些问题，就酝酿出来了这种新的开发、运维和使用一体的IT模式，云原生。

云原生的概念在一致的变化，在目前为止有几个特征是必须具备的：

（1）微服务：这是为了应用从模块、组件的颗粒度进行解耦。譬如：登录认证模块、人员权限模块、人员资料模块，会设计成3个微服务应用。并且为了应对登录、权限、人员资料的使用频次，都进行多实例副本的部署。如：登录经常发生需要部署3个实例副本、权限每次业务操作都要核实所以部署了2个实例副本、人员资料查询修改频繁只需要有1个实例。

（2）容器化：容器化是虚拟化的更进一步，连操作系统都不需要再搞一次，能省下更多被操作系统重复占用的硬件资源。并且应用被打包成镜像之后，里面还包含必要的运行库，运行环境也不需要重新搞。

（3）分布式：不能因为一台机器坏了，整个应用都Down了。所有的应用、存储、功能都要有多个子节点。其中一个坏了，其他节点能马上顶上来，也能分摊访问压力（负载均衡），甚至支持不许冷重启的立即弹性能力和节点伸缩。

（4）DevOps：DevOps是一种研发、发布、运维互不影响的连续一体化开发模式。就是通过前面3点的实现后，就能随时开发、随时发布、随时上线、随时运维调整，都不会影响的正式(生产)系统的使用。让开发人员没有验证功能的限制，升级对用户使用无感，运维调整对开发人员和用户都是不产生实际影响的。

（5）多租户：同样是基于前面4点的实现，多租户和为了共享硬件和软件资源的基础上，让更多有相同需求的人能用到同样的功能，但是数据和配置是独立隔离的。譬如：A开的一个卖货的店铺，B也能开一个一模一样功能的店铺，虽然功能一样，但是数据和配置都是不一样的。甚至可以为不同的用户（商户）给不同的功能或版本来按需“区别”对待。

（6）高适用：能使用私有化、公有云、私有云，混合云，还能选择IaaS、PaaS、SaaS方式进行结合、对接的使用。

二、云原生的门槛

我们从上面的概念看到都是优点，但是这些优点都是有成本和代价的。企业除非用的是厂商的纯SaaS，并且只需要这单一SaaS就能满足其需求，不用管后台究竟是不是云原生。不然，难度就会几何级的提升。

（1）有云原生能力的IT团队

最低要求：起码有一个真懂云原生的架构师，最好是从云厂商大厂出来的。不然你压根无法判断供应商给你提供的产品具不具备上面的优点。

基本要求：有一个至少能做DevOps管理的IT团队，其他都可以交由供应商来做，维度DevOps的管理需要自己把握好。

进阶要求：在前面的基础上，核心系统有自己的实施和定制开发能力。譬如ERP系统、OA系统。

高级要求：在前面的基础上，有自己的产品、研发、测试人员。哪怕核心系统是别人提供的，但是能自己做调整和改进。

完整要求：有一个专业的团队来做大部分自己的个性化应用，当然还是需要对接别人优秀的系统应用作为补充。

（2）有庞大的用户群高可用需求

高并发需求：有大量的数据、大量的用户需要使用。

超多系统对接：有超级多的系统和使用场景，如：ERP、OA、SRM、SRM、SCM、MES、IM…等很多的三方系统需要集成互通之后再归整为新的业务和应用场景。

多使用场景：有PC、APP、小程序、H5、嵌入三方系统等多端需要体验统一、权限统一、逻辑统一的使用需求。

（3）巨大的IT软硬件资源投入

资源需求：因为搭建一套能支持云原生的平台，需要大量的服务器、网络资源和出色的运维能力团队。

软件资源：要搭建起一套云原生平台，需要熟悉相当多相关管理工具、开发工具。虽然不少是开源免费的，但是很少人员或团队能完整把所有大大小小的运维和管理工作自己承担下来。

资源需求和优点矛盾：看到这了，你可能觉得云原生非常矛盾。云原生概念的初衷应该是能节省大量硬件资源、运维时间的。怎么现在入门的门槛如此的高？你要知道，省的前提是要有超大型的应用并对比传统IT模式才能看得出来。如果只是相对不复杂的IT应用，传统模式可能更具性价比和优势。并且使用了云原生，不代表要抛弃所有原有的IT架构和能力。

譬如：

• 每个人的电脑上安装的各种应用程序还是更多更大更复杂了，这是PC时代开始就一直不可逆的情况。使用SaaS、云原生这样的新手段可以减轻PC的负担，但是总体负荷还是逐年上升的。

• 单机系统、CS系统还是有强大的生命力。单机的财务系统，只是做简单总账还是比大型ERP要方便灵活得多。十几到几十人的公司，安装一套简单的客户端服务器ERP一般还是更加合适的。

• 很多工具型的创新，在处理和解决一些问题上也会有奇效。你总能找到一些新方式来解决一些问题。如AI的应用模式，每个月都有新体验。一年前ChatGPT，大家都想尽办法怎样去体验。现在不论是一些大公司，还是文心一言、清华团队、VIVO小蓝、小米小爱都能免费试用。Stable Diffusion这样的模型从需要专业AI显卡到现在纯CPU都能跑得动。

三、原云生的启用

如果我们确实需要启用云原生的IT模式，要怎样开始呢？

（1）本身就是提供SaaS服务的厂商，最好就是尽快启用云原生的架构方式。因为用户量和应用一有暴增，暂时还真只有云原生的方式最简单快捷。

（2）公司内部的IT系统需要微服务化的改造，也可以考虑一步到位用云原生的方式来搭建。

（3）新的系统和旧系统替换选用云原生的方式。

四、云原生的误区

（1）更加省钱：这是相对而言更加省钱的而已，因为硬件的虚拟机化、应用部署和开发的便捷化、开源软件的授权费都是直接成本，所以账面计算上看起来的支出少了。但是很多时候会忽略间接成本的增加。

• 运维成本的增加：因为大量的开源软件，对运维人员保障一套集开发、测试、生产环境于一身的服务集群有极高的要求。而且开源软件更新迭代的速度极快，开发人员要一个新特性需要升级某一个基础组件的难度是巨大的。还包括网络、安全的难度也是几何级的增加。
• 设计成本的增加：设计一套基于纯微服务架构的软件难度是非常大的，首先很容易导致这套系统没有人能清楚搞懂其中的细节关节设计，导致每个微服务的开发负责人或团队各自为政，测试难度加大，出现bug了更加容易推卸责任。内部接口过多，也会影响性能，影响设计的可理解性。为了更高的做设计，还需要更多的软件去补这方面的短板。从而系统会越来越复杂，越来越难以有效评估和控制。

（2）更加敏捷：敏捷是基于开发功能拆分到更小的微服务就能能快速上线验证的交付的前提。但是原来越多的需求是复杂化的，一个很小的需求可能设计十多套系统、数百个接口、上千次服务调用才能完成。为了响应速度还可能为这一个小需求增加不少的计算资源成本做存储、做缓存、做运算。试错成本看起来不高，但是因为需求冲突、功能闲置、重复需求被多次用不同方式重复实现的问题会更加容易发生，而纠正成本也极其高昂，因为能运行的代码一般人还不敢去动，特别是现在人员流动率超级高的IT部门、互联网公司。人走了就是等于代码推倒从来，因为去理顺前人留下来的屎山代码更加耗费时间。更何况可能很多功能实现都是优先考虑实现性，在git上面下载个现成的，能成本跑通就马上交付了，基本上以后不会再改。有新需求基本上重做一个，找新的实现方法。

（3）更加轻量：因为轻量这个词是基于用户端用更加简便的操作，应用开发的量更加少来衡量的。而实际上只是把很多复杂的事情全部丢给后端，后端一层层的应用搭建起来，每一层的依赖都非常强。应用层是解耦了，但是其他层次的复杂性是增大了，需要更加多的投入来完成运维、网络、安全、硬件部署的工作。