【时速云答疑时间】第七期:微服务设计模式及在时速云平台上的应用

为促进Docker、Kubernetes等技术的交流传播,同时帮助用户更全面地了解时速云产品及其应用,时速云每周四晚8:30-9:00在用户微信群进行产品、容器技术相关的直播分享和现场答疑。以下整理自10月22日第七期答疑内容,由 时速云工程师 赵帅龙分享。

之前我们谈容器时,通常会提到轻量级、快速部署、迁移方便等,这些优势大大方便了应用的部署、测试和升级,我们通常是从运维的角度去看待容器的。

docker作为容器技术的主干力量,目前已经被很多公司使用,但仅限于开发和测试环境的搭建,对于应用在生产环境,只有少数的大公司做到了。比如,腾讯已经将其应用在非核心业务上,而京东已经用于核心业务。之前我们也分享了一篇文章,http://blog.tenxcloud.com/?p=878, 文章提到,明年容器将在生产环境大规模采用,我认为即便不会,也会比今年增加很多。

既然离生产环境越来越近了,我们不得不提到容器技术对于开发者,对于系统架构的影响,这个也是最近讨论越来越多的一个概念:微服务,什么是微服务?微服务有哪些优势?哪些劣势?

这里我们首先提一下传统的架构。传统的软件架构通常是自上而下的,模块间耦合度比较高。一部分原因是主流的编程语言(C/C++、Java等)是过程式或面向对象式的,便于实现流线型的程序。人的思维方式也倾向于一步一步来,能看到可控的结果。纯粹的函数式编程语言如Haskell,被scala,go等各种抄,但始终火不起来,也有一部分原因是人的思维方式不习惯。

传统式的软件架构,对于小并发的程序处理起来得心应手,但是这个时代是万物互联的时代,twitter、facebook、微博、微信等社交应用对高并发的需求越来越强烈,搜索、大数据、cdn等同样需要应对高并发。然而单个机器的处理能力有限,所以自上而下的软件架构越来越不入流。我们希望服务可以横向扩展,请求量大时,可以动态扩容,请求量下降时可以动态缩容,所以就有了微服务。同时呢,对于请求量不太高的多数时候,我们又不希望资源浪费,而云服务可以满足这个需求。所以微服务和云服务搭配使用是极好的。
总的来说,微服务需要横向扩展,横向扩展需要降低耦合。所以我理解的微服务是: 对内,一组微服务是相互独立的进程,通过轻量级的协议交互(比如http RESTAPI、RPC),它们可以相互独立的部署和升级,可能使用不同的编程语言实现,对外,一组微服务作为一个整体,一个应用为用户提供不间断的服务。一部分人会把微服务当成SOA的衍生,这倒也说得通。

下面给大家分享几个微服务常用的设计模式。

首先我们说下 大使模式,Ambassador pattern,这个也是docker官方推荐的设计模式之一。https://docs.docker.com/articles/ambassador_pattern_linking/,。

我们以nodejs web应用为例,redis作为数据库

7答疑1

这里充当 “大使”的 是 Redis Proxy容器。我们不妨逆向思维一下,如果不使用Ambassador模式,于 Nodejs Web的代码中,访问redis的接口调用散落各处,Redis Server的变化意味着接口的变化,接口变化以后,加班修改 Nodejs Web的代码吧。

使用了Ambassador模式,将 直接访问redis的接口调用抽离出来,为NodeJs Server提供一致的接口。Redis Server改变以后,Nodejs Web不用修改,只需要修改 Redis Proxy的 接口调用方式就ok了。

多数时候,这里的“Redis Server”是第三方的服务或者组件,我们通过 Api调用该服务,不同的服务器上第三方服务/组件 的版本并不一致,很多时候都会共存。一些已经运行很长时间的业务一般不会轻易升级组件,我们部署新服务的时候可能需要采用一个代码库的不同版本。使用Ambassador模式的话,业务逻辑代码和调用第三方服务/组件的代码是分开的, 使用同样一套业务逻辑的代码就ok了。而访问第三方服务的 模块代码量一般不大,修改起来也比较快,更新以后,build一个新的image,可以很快上线。

Q&A精选:

1. 微服务会有依赖,怎么管理?
答:目前一般的应用都会提供 http 的restful api接口,如果是tcp的话可以采用rpc的方式进行通信。多个服务可以link起来

2.有个问题,虽然多个微服务之间做到解耦合,以rpc或者restapi的方式调用,但是在部署到多个docker以后怎么知道docker容器之间关系?
答:目前Docker Compose可以定义 不同容器的关系,即通过link的方式。k8s也支持服务编排(yaml或者json文件可以定义),pod内多个容器通过localhost互相访问。

3. 微服务带来的架构复杂成本、管理复杂成本、运维复杂成本和传统的架构下逻辑的复杂成本到底哪个更划算?
答:复杂度和成本的权衡更多是业务来决定的,如果业务对并发要求并不高,或者目前的架构通过 增加机器的配置或者网络的带宽能够满足业务的需求,把架构改成微服务肯定大家都不乐意。对于管理的复杂度,更多公司愿意多招些运维,而不是重构来实现。

4. 如果client和kafka节点没有做网络隔离,client可以正常访问kafka数据。但是如果存在网络做隔离,就访问不了,不知道redis集群会不会有这个问题,如果有,有没有解决方法?
答:kafka节点和client不在一个局域网,kafka节点又没有暴露外网地址的话,确实会连不上。redis原理不太一样,client能连接到redis的一个节点,就可以访问redis集群的所有数据。对于你说的问题,可以在 kafka cluster的同一个局域网里部署一个proxy,client去连proxy,也可以在client端 通过vpn连过去,proxy的方式更方便点。

后记:有兴趣参与每周四晚8:30-9:00时速云产品、容器技术相关答疑的用户朋友请关注时速云微信公众号,留言给我们您想了解的问题或对时速云产品的体验感受,我们会第一时间回复您。

暂无评论

发表评论