欢迎光临
我们一直在努力

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

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

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

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

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

如果用上了 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,我们都有美好的未来。

文章来源于互联网:做云自缚——应用上云之路

赞(0)
未经允许不得转载:莱卡云 » 做云自缚——应用上云之路