做云自缚——应用上云之路

今天扯个闲篇，说说应用上云的事情。

最近这几年，一直都在围着“应用上云”这四个字转悠，看到很多成功的和不太成功的应用上云活动，是的——一个失败的都没有，所以云原生真是厉害，对吧？

应用上云成功了会怎么样呢？一般成功案例会共享的几个好处：

• 应用更快交付、能用更高的频率迭代
• 更高的应用密度，更有效地使用资源
• 监控日志等可观察性方面的增强
• 弹性伸缩在削峰填谷方面的卓越表现
• …

如果用上了 Service Mesh 或者类似微服务治理技术，多半还会提到分布式追踪、熔断、限流等的好处。

然而面对这种种诱人后果的展示时，很多像我一样的中老年 IT 人可能都会发出一句常见的老年人诘问：这些东西以前没有吗？

• Jenkins 的前身 Hudson 诞生于 2004 年，2011 年定名 Jenkins。
• Maven 大约诞生于 2001 年。
• SonarQube 大约诞生于 2007 年。
• Zabbix 也二十多岁了。
• SpringCloud 其实跟 Kubernetes 几乎同龄。

所以是什么让云原生的林林总总从厚重的历史中脱颖而出的？我认为是 Docker，那个 “Build once, Run anywhere, Configure once, Run anything” 的 Docker。在 Docker 出现之前，IT 界为了造词疲于奔命，从 CMM 到敏捷、从 CI/CD 到 DevOps，另外还有十二要素、微服务、重构等等的方法。而 Docker 出现之后，随着 Google 不断的勒索，Docker 提出的容器镜像打包和运行标准，逐步“贡献”出来成为开放标准，CxI 已经成为云原生世界中最重要的标准群。

名言说：无产阶级失去的只是枷锁，而他们获得的将是整个世界。而我理解的云原生，跟这个口号恰好相反——软件通过自投罗网的方式，交出部分自由，获得自称云原生的资格。“自废武功”的应用有多不自由呢？

• 要清楚地了解从操作系统、构建系统、软件库等的依赖，用内聚的方式进行打包，形成单一的容器镜像（文件）
• 为了能在通用且较为低配的容器节点上顺利运行，通常需要对软件的资源规模有一个足够进行量化的认识，甚至需要为了资源、容量等问题对应用进行拆分。
• 为了进行扩缩容，微服务提供的服务接口要努力摒弃状态，实现幂等，甚至还要完善健康检查、优雅退出等以前不关注的边角料功能。
• 甚至连临时文件和日志都不能随意输出了。
• …

在应用屈服了之后，过去一直无法施展拳脚的很多方法和工具也焕发了新生——例如 DevOps、敏捷、微服务，甚至还诞生了更具通用性的服务网格、更大跨度的分布式追踪等“更厚”的基础设施。这些先进又复杂的底层设施，因为面对的是具备通用性的业务应用，也具备了明确的支持能力。

结论

好好打镜像，好好写 YAML，我们都有美好的未来。