从Docker的转变,谈容器生态与微服务的发展

我们看 PaaS / CaaS 的区别和各自的市场,PaaS 的思路基于应用平台,而 CaaS 并不限于应用平台,因此它也并不能理解应用平台的问题;所以两者面对的市场还不太一样,如果着眼于应用平台那 PaaS 比较好,如果是希望把各种资源管理起来,当做虚机使用,通过容器实现,那 CaaS 比较好。

关于 Docker 和微服务

我认为将 Docker 等同于微服务是一个误导性的看法。微服务由两个组成部分:运行环境(运行于容器中是很好的运行环境的选择),开发框架(比如服务动态注册、发现和调用等)。业内很多人只重视到了第一部分,而忽略了第二部分,比如 Docker 微服务化最常见的就是微服务的动态发现和调用则几乎完全依靠第三方平台来实现,如 ZooKeeper、Consul 等,但是这些工具的缺点是当集群达到一定量之后就会出现不稳定的问题,而且平台要适应各种代码需求有困难,我认为程序的事情归程序来解决,而不是平台。最佳实践是采用程序框架从根本上解决问题,比如 Netflix 就进行了彻底的改造,他们的服务注册、发现、治理、限流都是通过程序框架(也即后来的 Spring Cloud )来实现的,经受了大规模的应用考验。用平台解决代码层面问题是有缺陷的,因为平台解决的是平台问题,不能包揽代码的工作;代码框架是解决代码的问题:服务注册发现更适合在代码层面实现。

当然,微服务还有一个更关键的问题:如何对服务进行合理的分解和定义,不是说巨石应用随便按模块拆分就可以了。经常会有人问,微服务对业务进行升级以后多个模块如何一起部署,问这个问题就是微服务没有做好,学了微服务的形,没有学到微服务的实质,最终微服务的效果也会大打折扣。问这个问题的根源在于微服务解耦的不好,没有遵循微服务分解的方法论。如果微服务分解的好,那很大程度上是可以单独部署而不会影响其他模块。

微服务做好了以后怎么运维?故障发现、自动恢复,根据业务请求量的弹性伸缩等等这些工作,要么通过 PaaS 去自动实现,要么自主研发实现,但是这样工作量很大。最终,微服务的价值在于让开发人员只关注业务逻辑代码,不用关注非功能性相关的技术问题,这些技术问题交由微服务框架和运行环境来解决,而且微服务最终要能通过平台实现运维自动化,就是未来的热点" NoOps ",目前的 ServerLess,Serverless 不是目的,目标是 NoOps.前几年谈 NoOps,大家总觉得太遥远,其实 PaaS + 微服务,使得 NoOps 越来越近。

下一个技术热点: 数据微服务

容器是 2015 年最大的热点,但是 2016 年容器的热度在下降;2016 年的热点是微服务;2017 年我认为是数据的微服务化。

为何认定是技术热点?

之所以认为数据服务在 PaaS、CaaS 上的框架这个会成为新的热点,是因为:首先这个技术是微服务的延续,而且是必然的延续,微服务已经解决了运行环境-容器的问题,又解决了框架的问题- Spring Cloud 和 Spring Boot,下一步就是数据的问题了,而且数据服务化还没有完全成熟。其实一个技术成为热点的时候就是它的对应技术方案即将成熟又未成熟之时,容器和微服务成为业界注意力中心的时候都是这样,也就是大家对它将懂未懂,最需要了解的时候,这种状态就是技术热点状态。

以今年火爆的微服务为例,SpringBoot 很早就开始有研发;2014 年以产品形式出现,但是当年月下载量是十万级别,而今年单月的下载量就可以上千万,两年不到增长百倍,这就是热点。根据数据服务化的相关开源项目在社区的反馈和贡献量来看,现在也快达到了同样的临界点。

并且,创建大数据应用仍很痛

现在做大数据应用,需要装很复杂的大数据环境。如果将其服务化,只需要点击创建即可,使用者不必关心后面的 GreenPlum、Hadoop 等是怎么安装部署的。Hadoop 那么多组件,一个个安装太麻烦了。

目前我们做的数据服务化的技术储备包括大数据服务化、数据服务化、流数据服务化,这三类技术正在逐步达到生产可用……因为大家做完应用之后就开始考虑数据怎么办,数据按照传统方式来做是肯定没有问题的,但是应用微服务之后,要求数据要和微服务应用对应,原来的巨石应用分拆为微服务了,那原来的大一统的大型数据库,也要根据微服务进行拆分,拆分之后要分析数据是用传统的 SQL 数据库,还是新的 NoSQL,或是缓存加持久化。所以我认为这个就是将来热点。以 Spring Data 为例,它负责数据抽象,至于最后落到哪类数据库 MySQL、Oracle 甚至是 NoSQL 类的 MongoDB 的技术细节,开发者不必关心,到部署的时候再绑定,这就要求数据能够服务化。