没有PaaS的Docker,我们能实现真正的微服务架构吗?

小数预告! 5月26日 · 数人云邀您参加企业级Docker盛会
时间:5月26日 13:30 地点:北京万达索菲特大饭店七层 大宴会厅 I 厅

请别急于投身微服务洪流而将application servers丢弃在一边。

传统的按照应用来分配服务器的方式已经过时。至少对于大多数布道者甚至某些企业软件供应商来说,目前的情况就是这样。在他们看来,建立自容纳型微服务、继续使用与以往同样的技术并将其部署在容器中或作为独立应用才是跟得上时代的作法。

没错,微服务的思路是极为令人赞赏的。微服务强迫我们利用经过良好定义的接口进行通信,提供独立性更高的更新与测试机制,同时也能让我们的简历变得更为抢眼。遗憾的是,没有PaaS作为辅助,很难想象如何在实践层面建立起自容纳、自托管型微服务架构。

问题在于GitFlow。很多朋友一定都曾使用过其某些版本或者至少听说过这套方案。不过考虑到也许有些朋友对其不太熟悉,这里再做些解释。GitFlow的基本目标在于帮助开发者在分支当中实现、测试并验证新功能,而后将分支加以合并从而把变更纳入主线当中。

通过以上示意图,可以看到每个点都代表一款已部署应用程序。如大家所见,GitFlow鼓励我们建立多个分支,这意味着将成果真正纳入生产环境之前,其中存在着大量需要部署的应用开发版本供相关人员及自动化测试工具进行验证。

对于仍然坚持使用application servers的朋友,测试与验证新功能的流程非常简单:将我们的WAR上传至惟一背景路径,在隔离环境下进行测试,并在代码合并或者被弃用后删除该WAR。整个分支生命周期可通过各类app servers中所常见的CLI工具及管理控制台进行创建,而且对大多数build servers而言,与app servers相整合更是小菜一碟。

当然,这并不是说以功能为单位进行WAR部署就真的毫无难度。任何曾经采取过这种方式的朋友无疑都经历过PermGen内存错误——这是因为大家推送的内存模型并不适用于应用程序的持续加载与卸载场景。但其处理办法也非常简单,大家可以升级至Java 8,其metaspace实现机制能够为大多数团队提供理想的工作平台。 ​ 一旦app server调整就绪,即能够很好地支持开发人员与GitFlow进行协作。硬件配置相当低的app servers(例如WildFly)都可以托管超过200个WAR文件,而开发者们则能够将各类应用程序变更提取至分支当中。

很明显,这些配置有限的服务器无法承载200多Spring Boot或者WildFly Swarm UberJars所带来的沉重压力。另外,200其实是个非常保守的数字,因为微服务天然鼓励用户使用大量独立应用。而在测试过程中,针对不同环境所产生的应用程序具体版本在数量上也会变得更加夸张。当大家审视这些数字时,就会意识到:

微服务 x GitFLow = 大量部署

不过这里不得不说,很难想象大家要如何在简单的Linux设备上实现UberJars功能分支的生命周期管理。该如何管理这些端口?需要使用哪些命令对UberJars进行部署、启动、停止并取消部署?又该如何查询服务器以找到当前正在运行的应用程序并将其交付给测试人员及其他相关人员?

Docker能够解决其中大部分问题,但Docker本身并不属于管理工具。维护容器fleet需要配合Kubernetes或者Atomic Host等方案,甚至是完整的PaaS环境,如数人云(小数举例说)。

实际情况是,没人有时间手动处理持续集成与交付环境下的部署工作。App servers能够为大家带来一套经过定义且久经考验的解决方案,足以对由GitFlow提供的各类临时性应用的生命周期加以管理。而且任何有意转向微服务架构的朋友,都需要具备同等水平的管理能力,这一般也就意味着需要一个方便轻量的PaaS平台。如果没有这一保证,开发人员将需要耗费大量时间来手动部署其应用程序,而企业也将浪费巨额资金来购置用于托管这些功能分支版本的资源。