一个创业公司的容器化之路(三) – 为什么要用容器

创业公司应该使用容器的4个原因

前两篇文章(一个创业公司的容器化之路(一) - 容器化之前一个创业公司的容器化之路(二) - 容器化)我们介绍了杏仁架构的发展历程。我们再回顾一下第一篇开头提出的三个初创公司的技术挑战,

  1. 如何快速、低成本的搭建系统,同时确保安全稳定?
  2. 如何快速的构建和发布应用,满足业务需求?
  3. 如何提高团队开发效率,确保开发质量?

杏仁通过容器化来应对这几个挑战,也取得了一些成就,但也说不上完美的解决。毕竟我们规模还小,很多方案也只是在我们这个规模刚好够用。不过在这个过程里,我们还是深刻体会到了容器化的价值。正如我介绍容器的时候说的,容器会和集装箱一样,成为一个标准化的基础设施,对上层应用产品革命性的影响。

很多大厂其实一、两年前就开始做容器方面的尝试。但现在,我们认为其实初创公司也应该考虑应用容器了,原因有以下几点。

1. 容器生态已经成熟,容器服务和容器云可以大幅降低容器使用成本。

去年容器编排还不能说很成熟,例如 Kubernetes 还存在不少缺陷。但经过一年时间狂飙猛进,Kubernetes 今年已经很成熟了,有不少企业已经在生产环境使用了 Kubernetes。部署和运维也比之前简单多了。

另一方面,各大公有云也都推出了容器服务,还有不少独立的容器云公司。如果你是用公有云的话,推荐直接使用相应的容器服务,可以快速的搭建系统,大幅降低运维成本,提高效率。

并且这会带来一个额外的好处,因为这些容器服务都是基于 Kubernetes 的,而容器本身就是一个标准化的东西,使用容器服务反而可以降低对公有云服务的依赖。在公有云的容器服务之间迁移,或者后期打算自建然后迁移,都不是很难的事情,

2. 容器使创业公司可以轻松的应用行业最佳实践,创建优质应用。

几年前有人提出了一个十二要素应用的最佳实践,我认为是一个很好的标准。

下面列表对这十二条实践进行了分析,我分成了三种情况,分别用三颗星、两颗星和一颗星表示。

  • 三颗星:没有容器实践起来很困难,容器环境下可以很容易实现。
  • 两颗星:没有容器也可以实践,但在容器环境下可以做得更好或更轻松。
  • 一颗星:没有容器也可以实践,容器环境里也能支持。
最佳实践 支持程度 说明
基准代码:一份基准代码,多份部署。 ★★ 不仅一份代码多份部署,容器能做到一份镜像,多分部署。
依赖:显式声明依赖关系。 ★★★ 容器通过 Dockerfile 管理内部依赖,实现自包含;容器编排管理服务依赖。
配置:在环境中存储配置。 ★★ 容器通过环境变量传递配置;容器编排能提供标准的配置工具。
后端服务:把后端服务当作附加资源。
构建,发布,运行:严格分离构建和运行。 ★★ 通过 docker build 构建,通过 docker run 运行,严格分离。
进程:以一个或多个无状态进程运行应用。 容器对无状态应该可以完美支持,有状态应用现在也能很好支持。
端口绑定:通过端口绑定提供服务。 ★★ 容器编排可以处理服务依赖和绑定,应用不再需要关心。
并发:通过进程模型进行扩展。 ★★★ 容器编排可以很轻松的扩容。
易处理:快速启动和优雅终止可最大化健壮性。 ★★★ 容器编排可以支持快速启动、优雅终止,具有自愈能力。
开发环境与线上环境等价:尽可能的保持开发,预发布,线上环境相同。 ★★★ 容器的可移植性和自包含,能做到随处运行,但应用的环境依然保持一致。
日志:把日志当作事件流。 ★★ 容器和容器编排可以很好的支持日志。
管理进程:后台管理任务当作一次性进程运行。 容器编排提供了多种方式可以运行一次性任务。

所以可以看到,在容器环境下,可以很轻松的实践这十二要素,从而使得应用更容易开发、维护和部署。

3. 容器使创业公司一开始就可以以极低的成本应用微服务架构。

这张图很多人应该看到过,是 Martin Fowler 提出的关于微服务和单体应用的生产率趋势的比较。

productivity.png-102.3kB

这张图要表达的意思是,如果团队使用微服务,开始可能需要花费更多的精力来搭建基础设施和架构,但是生产率可以一直维持在比较高的水平。而在创业公司,我们一般会为了速度,采用 Quick & Dirty 的方案,也就是创建一个单体应用。一开始这样会很快,但问题是,单体应用会越来越庞杂、越来越难以维护,此时就会严重影响团队生产率。

当生产率下降到一定程度时,团队会开始考虑服务化(包括我们杏仁也是这么做的)。但在服务化的过程中,会消耗更多的人力和资源,严重影响生产率。服务化完成之后,生产率会有一定提升,但也很难一下子达到微服务的状态,需要不断的重构并拆分服务。所以在互联网,其实大部分稍微有点规模的公司的生产率曲线是这样的:

productivity2.png-51.9kB

但是在容器环境下,一开始就使用微服务的话,其实生产率并不会比单体应用低多少。

productivity3.png-58.6kB

这是因为容器已经提供了微服务所需要的很多基础设施,包括服务注册和发现、服务依赖和生命周期管理、负载平衡等,而且健壮性和资源利用率也会更高。如果是直接使用容器云,则运维的成本也很低,只需要关注微服务的业务架构就可以了。

所以在容器环境下,我们没有理由再去创建一个单体应用,一切都是微服务,只要业务架构设计合理,研发团队可以更专注于业务开发,生产率可以一直保持在较高水平。

4. 容器使创业公司降低运维成本,提升运维效率,轻松实践 Devops。

容器环境下,很多以前的日常操作都自动化或至少半自动化了,比如比如部署、发布新应用、扩容等等,都可以很快速的响应。容器编排的自愈能力,即使除了问题,也可减少人工干预。

所以容器环境下的运维是幸福的,不用在苦逼的响应各种需求,可以吃着火锅唱着歌把事儿做了。大大加强了运维的幸福感,终于运维同学也可以开开心心的去谈恋爱了。

而开发也可以对自己的应用有更多的掌控。除了能快速频繁的部署,也可以从日志、监控中得到数据和反馈,出现问题也可以通过工具一定程度上去进行调试。

容器即未来

所以,正如上一篇说的,基于容器,会逐步建议一套完整应用架构体系,而这套体系会带来革命性的改变。所以,容器即未来,而未来已来到眼前。

容器容器容器

0

我们正在招聘Java工程师,欢迎有兴趣的同学投递简历到 rd-hr@xingren.com

发表评论

电子邮件地址不会被公开。 必填项已用*标注