微服务设计模式与容器云平台

杨乐 2015-11-27 09:39:58

 

11月25日,时速云联合创始人杨乐老师,在【DBA+社群】中间件用户组进行了一次主题为“微服务与容器云平台”的线上分享。小编特别整理出其中精华内容,供大家学习交流。同时,也非常感谢杨乐老师对DBA+社群给予的大力支持。

 

嘉宾简介
 
 

  • 时速云联合创始人

  • 主要负责时速云产品基础架构、研发和产品安全等工作


内容摘要
 
 

介绍基于Kubernetes的微服务特性,及在容器平台上所创建的容器服务其背后所具有的弹性伸缩、自启动、微服务架构等特点。


演讲实录
 
 

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


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


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


我们不妨考虑下面几个问题:1. 服务升级是否频繁,单次耗时情况怎样,升级时能否提供不间断的服务;新版本的应用意外崩溃,打热补丁的时间,服务是否会中断;2. 新增feature时,是否需要整体重新部署或者重启核心服务,是否需要重新测试已有功能,服务是否会中断;3. 出现故障的原因,多少是因为程序本身的bug,多少是因为部署/升级时的人为疏忽或者沟通不畅;4. 随着用户的增长,关键组件(服务)是否能够水平扩展。如果考虑系统升级频率较高以及希望热升级避免服务间断,而且面临上面提到的问题的话,微服务架构很可能是个不错的选择。


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


1
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了。



2
SideCar模式(伴随者)
 

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



3
Adaptor模式(适配器)
 

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


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



实际上前面所举的模式需要在容器的技术基础上,平台具有弹性伸缩动态更新的功能,而例如像伴随者模式,这个服务伺服变动频繁,体量微小,最好能与主服务共享部分资源并且共存生命周期。这个在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格式以指定的组合对服务进行构建。同时利用控制器维持服务的可用性。




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


再次感谢时速云联合创始人杨乐老师,对DBA+社群活动给予的大力支持!

 
 
 

“DBA+社群”将陆续在各大城市群进行线上专题分享活动,以后每周一、周三晚上为【DBA+专业群】的固定时间,每周二、周四晚上为【DBA+各城市群】的固定时间,每周五晚上为【DAMS架构师精英群】的固定时间,欢迎大家积极加入我们。无论是内容还是形式,有好的建议我们都会积极采纳。


想入群的小伙伴们请关注DBA+社群微信公众号:dbaplus,回复“加群”即可。

 

小编精心为大家挑选了近日最受欢迎的几篇热文:

回复001,看丁俊的《【重磅干货】看了此文,Oracle SQL优化文章不必再看!》;

回复002,看《灾备故障上了红头文件,容灾技术到底哪家强?》;

回复003,看吕海波的《去不去O,谁说了算?》;

回复004,看胡怡文《PG,一道横跨oltp到olap的梦想之桥》;

回复005,看付新《达梦专家解读:国产数据库也疯狂》;

回复006,看郭耀龙《假事务之名,深入研究UNDO与REDO》;

回复007,看宋日杰《Oracle后台专家解决library cache锁争用的终极武器》。

 


最新评论
访客 2023年08月20日

230721

访客 2023年08月16日

1、导入Mongo Monitor监控工具表结构(mongo_monitor…

访客 2023年08月04日

上面提到: 在问题描述的架构图中我们可以看到,Click…

访客 2023年07月19日

PMM不香吗?

访客 2023年06月20日

如今看都很棒

活动预告