【干货分享】微服务设计模式与容器云平台

11月25日,时速云联合创始人杨乐,在DBA+社群中间件用户组进行了一次主题为“微服务与容器云平台”的线上分享。现整理出其中精华内容,供大家学习交流。

什么是微服务,用Martin Fowler的一段话:没有一个明确的定义,但简单来说是,以一组小型服务来构建成应用,每个服务运行在单一独立的进程,不同服务间采用轻量级的交互机制来通信,例如HTTP(REST API)。这些组成应用的服务围绕业务能力来构建,完全采用自动化部署方式,可独立部署扩展,不同的服务可以采用不同的编程语言来实现,由独立的团队来维护。

实际上多年前的所谓的SOA面向服务架构,现在的微服务架构依然是SOA的一种思想实现。微服务的特点还是显而易见的,组件化,独立部署,传统实现组件的方式是通过库(library),C++ java通过静态或动态链接构建成软件,不强调进程分化,升级时需要整体重新部署或服务重启。但微服务的方式把他们各部分拆分了,变成一系列服务以进程的粒度运行,意义就在于,升级部署时,只需局部更新过时组件,而不需要牵动整个系统。当然这种跨进程的调用方式需要考虑边界问题,也就是各组件的容错性,在设计之初需要考虑各部分明确职责。

容器技术的逐步成熟给DevOps带来了一场变革,也给微服务思想的实现提供了便利。当我们讨论容器技术的优势时,通常会提到轻量级、快速部署、迁移方便等,这些优势大大方便了应用的测试、部署和升级,而很少提到开发。DevOps的目标是整合产品开发、测试、部署和维护,保证产品的性能和稳定性,同时加快新功能的开发和上线。借助于容器技术和微服务架构,开发真正融入到产品交付流程中。

我们不妨考虑下面几个问题:

1.服务升级是否频繁,单次耗时情况怎样,升级时能否提供不间断的服务;新版本的应用意外崩溃,打热补丁的时间,服务是否会中断;

2. 新增feature时,是否需要整体重新部署或者重启核心服务,是否需要重新测试已有功能,服务是否会中断;

3. 出现故障的原因,多少是因为程序本身的bug,多少是因为部署/升级时的人为疏忽或者沟通不畅;

4. 随着用户的增长,关键组件(服务)是否能够水平扩展。如果考虑系统升级频率较高以及希望热升级避免服务间断,而且面临上面提到的问题的话,微服务架构很可能是个不错的选择。

传统上,软件的架构是自上而下瀑布模式,模块间耦合分离采用调用库链接方式,一部分原因是主流的编程语言(C/C++、Java等)是过程式或面向对象式的,便于实现流线型的程序。微服务提倡的是便于横向扩展的应用,对内,一组微服务是相互独立的进程,通过轻量级的协议交互,可能使用不同的编程语言实现;对外,一组微服务作为一个应用为用户提供不间断的服务。下面我们介绍几个微服务设计模式,看看容器技术和微服务在生产中的应用。

一、Ambassador 模式(大使)

通常情况下,不同的服务会有一定的耦合,比如说nodejs web应用和redis服务、php web应用。我们以web服务和redis服务为例,来重现下可能的问题。

主服务要访问redis服务,所以必须知道redis是如何部署的。redis发生变化时,原先访问redis的方式通常会失效,这时候我们不得不重新修改主服务。但主服务代码中可能包含大量的业务逻辑,访问redis的代码散落在各个角落,给下次升级留下了很多潜在bug。如果把访问redis的代码从web主服务中剥离出来,放到一个单独的容器里,即 (web app)-> (Ambassador: redis proxy) -> (redis server),我们就不需要频繁修改web app了。

 

社群1

二、SideCar模式(伴随者)

使用SideCar模式,我们可以从外围对核心服务做一些增强工作。比如,在部署主服务容器时,同时部署一个用于日志搜集的应用容器,定时搜集并发送日志到日志服务器;或者监控服务容器,用以监控主服务的运行状态。主服务实例过多时,可以部署一个git同步服务容器,无需人工干预就可以定时更新服务器上的代码。

社群2

三、Adaptor模式(适配器)

这个模式主要是将应用适配到不同的环境中。例如,为跨云端的应用部署统一的监控系统,假如应用部署在AWS、阿里云等多个IaaS上,监控系统为了获取日志等信息可能需要针对每个IaaS厂商进行适配。

为了保证核心服务的稳定性和独立性,可以另外实现服务获取应用运行和运行环境信息,这个服务可以对不同IaaS的API进行适配。部署和升级时,主服务容器和监控服务容器同步创建和销毁。

社群3

 

 

 

 

 

 

 

 

 

实际上前面所举的模式需要在容器的技术基础上,平台具有弹性伸缩动态更新的功能,而例如像伴随者模式,这个服务伺服变动频繁,体量微小,最好能与主服务共享部分资源并且共存生命周期。这个在kubernetes的pod概念里有非常好的实现特性。

Kubernetes是集群级别的容器编排系统,是源于google的borg项目,它在构建应用时,物理和逻辑上构建了3个层次,即pod、replicationctroller、service。通过将一个或多个容器放入pod来实现最小调度单元,通过replicationctroller来实现pod的副本控制即弹性伸缩,service是逻辑概念,通过proxy的方式让多副本pod为上层服务提供负载均衡。Kubernetes本身支持多种网络类型,但自身并不解决多机集群的网络问题,还支持多种类型的分布式存储。

Kubernetes的Pod对微服务有先天的支持,Pod内的容器共享存储共享网络,这让处于微服务模式中的容器联系更加紧密。同时,控制器又可以对他们进行灵活的更新升级。比如Ambassador 模式,proxy的部分根据外部db的变化需要较频繁的更新,在k8 pod的内部与主服务是以localhost的方式通信,无需暴露到外部。 这样既可以充分利用Kubernetes在资源调度上的优势,也可以充分利用微服务的优势。Kubernetes中的Pod具有独立的IP,从这个角度来看,比容器更像一个虚拟机。将多个相关关联的容器应用部署在同一个Pod中,pod的生命周期由上层的调度机制决定,真正实现了松耦合、高可用和负载均衡。

在容器微服务方面,时速云支持docker本身的compose方式,支持多容器互联,只需要ymal格式以指定的组合对服务进行构建。同时利用控制器维持服务的可用性。

社群4

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

而利用主机产品,搭建私有的caas平台,将会具有更多的权限,支持较大数目的容器,未来会开通api,拥有对kubernetes更多的控制权限。

暂无评论

发表评论