zhuhaiqiang
作者zhuhaiqiang2017-08-08 15:26
项目经理, 银行

从一个实验看微服务架构---不谈理念讲干货

字数 3844阅读 2517评论 0赞 6

前言

由于篇幅有限,本文只先通过一个实现,简单介绍微服务的整体概念,如果时间允许,后续会分享更多此类文章。

微服务的概念

微服务的架构是针对传统单体应用而言的。

什么叫单体易用?简单理解就是通过一个单一应用实现若干业务功能模块。目前大多数应用都是单体应用。如: 在银行中,如网银(它本身就是三层架构,有web、App、DB),柜面,二代支付,它们虽然都是独立的应用,通过ESB互通并访问核心银行系统,但每个应用内部,都有很多功能模块。

单体应用有很多好处,如易于部署、测试便捷、运维方便。但随着业务需求不断增加,单体应用的代码被“修修补补”,往往变得异常庞大,复杂度越来越高、扩展能力变差。到最后的结果可能就变成这个庞大的应用“牵一发而动全身”,没人敢动、没人敢改,最终阻碍了技术创新。

那么,针对这种情况,我们如何能解决单体应用的问题呢?这就需要了解微服务的架构。

微服务就是将一个单一应用开发为一组小型服务的方法,每个服务是独立运行的进程,服务之间采用轻量级通讯机制。说简单点,就是一拆多。

微服务架构中最为关键的一点是:每个微服务都可以用不同的语言开发,使用不同的存储技术。

微服务架构中,每个微服务可独一运行、可独立开发、微服务之间使用Restful API进行通讯等。微服务好处很多:易于开发和维护、启动快、扩展性强等等。当然,它也有挑战:运维要求高、分布式系统复杂度增加等。

微服务的架构与适用平台

微服务的架构有很多,如Dubbo(阿里巴巴微服务架构)、Dropwisard、Armada等。当然,最出名的还是Spring Cloud。

微服务可以运行在很多平台上,如物理机+Linux、虚拟化+Linux,但微服务由于其本身的特点,更适合于运行在容器上。而Gartner的调查报告,容器主要适用于四种大的场景:

  • 敏捷开发(Developer workflow)

将容器应用于开发场景,也是容器最常见的应用场景。容器的轻量级很适合于开发人员提高开发效率。并且有助于构建持续集成和基础部署架构。

  • 批量运算(Batch computing)

批量运算如HPC、数据分析类的应用,或者高并发、短生命周期的应用。

  • PaaS或类PaaS服务

PaaS,也就是平台即服务。相比于虚拟机,容器显然更适合PaaS。如OpenShift是典型的利用容器提供PaaS的方案。

  • 微服务

微服务架构是一种特定的软件应用程序设计方式——将大型软件拆分为多个独立可部署服务组合而成的套件方案。容器的自身特点使它更适合微服务。

从实验入手--实验环境介绍

接下来,我们看一个通过容器实现微服务的实验。

本实验基于Openshift容器云平台构建。笔者在Openshift中创建一个项目helloworld-msa:

1.png

1.png

在这个项目中,创建多个容器,一共有四个微服务的容器(Hola、Bonjour、Aloha、Ola;其它容器下面内容会介绍)

查看容器(pod):

2.png

2.png

查看应用:

3.png

3.png

查看每个应用对外暴露的FQDN:

4.png

4.png

这些微服务,每个都用不同的语言开发,每个有自己的作用。其统一展现通过frontend这个微服务实现,通过浏览器访问其FQDN:

5.png

5.png

我们详细看一下各个微服务:

6.png

6.png

我们可以看到(1)Hola微服务是通过Wildfly实现、(2)Bonjour微服务通过node.js实现、(3)Aloha微服务通过Vert.X实现、(4)Ola微服务通过Spring boot实现。每个服务都运行在一个容器(pod)中,具有一定相互独立性,有通过restful API相互调用。

接下来,我们可以看一下,通过http访问每一个应用的restfulAPI

(1)Hola

7.png

7.png

(2)Bonjour

8.png

8.png

(3)Aloha

9.png

9.png

(4)Ola

10.png

10.png

微服务的API网关

既然本实验中的四个微服务,都提供restful API访问,那么,客户端的应用是否可以直接、随意地访问后端这四个应用呢?

这样当然是不合理的。客户端直接调用微服务的问题是,部分服务使用的协议不是Web友好协议。一个服务可能使用Thrift二进制RPC,而另一个服务可能使用AMQP消息传递协议。不管哪种协议都不是浏览器友好或防火墙友好的,最好是内部使用。在防火墙之外,应用程序应该使用诸如HTTP和WebSocket之类的协议。

此外,客户端直接访问微服务的API,会使得微服务难以重构。随着时间推移,我们可能想要更改系统划分成服务的方式。例如,我们可能合并两个服务,或者将一个服务拆分成两个或更多服务。然而,如果客户端与微服务直接通信,那么执行这类重构就非常困难了。

因此,需要使用API网关。API网关封装了系统内部架构,为每个客户端提供一个定制的API。它可能还具有其它职责,如身份 验证、监控、负载均衡、缓存、“请求整形(request shaping)”与管理、静态响应处理。

在实验中,笔者通过容器实现API网关:

先看AI网关容器,再看应用(本实验之所以有两个API网关,是因为笔者在其它实现中通过API网关模拟了蓝绿发布)。

11.png

11.png

最后查看API网关的FQDN:

12.png

12.png

而API网关对外提供的也是restful API:

13.png

13.png

我们继续看实验环境的浏览器展现:

14.png

14.png

客户端通过互联网微服务的时候,先请求先到API网关,然后按照如下顺序:

15.png

15.png

16.png
16.png

微服务的容错处理

有个词,叫“雪崩效应”,相信很多人都听过。它其实是从“雪球越滚越大”的现象抽象出来的。在单体应用中,多个业务的功能模块放在一个应用中(如三层架构的网银),功能模块之前是紧耦合,单体应用要么整体稳定运行,要么整体出现问题,整体不可用。

而在微服务架构中,各个微服务可能是相互“消费”的概念。以实验为例,如下图:

17.png

17.png

从客户端访问应用的时候(当然会先访问API网关,只是上图没有体现),会按照如下属于访问各个微服务:

18.png

18.png

按照上图,Ola是Hola的基础服务、Hola是Aloha的基础服务、Aloha是Bonjpur的基础服务。那么,如果Ola微服务出现问题,不可调用,那显然会影响到Hola的调用、Aloha调用、Bonjpur的调用。这就像雪球一样,越滚越大,越到后面,影响越严重。

要想避免雪崩现象,就需要有容器机制,采用断路模式。为每个微服务前面加一个“保险丝”。当电流过大的时候(如服务访问超时,并且超过设定的重试次数),保险丝烧断,中断客户端对该应用的访问,而访问其他好的应用。

微服务常见实现容错的工具是Hystrix。在笔者的实验中,Hystrix也被部署到一个容器中:

先查看Hystrix容器(pod),再查看应用:

19.png

19.png

查看应用的FQDN:

20.png

20.png

通过浏览器访问Hystrix,可以看到我们可以对其进行参数设置。

21.png

21.png

在本实验中,Hystrix已经集成:

22.png

22.png

接下来,我们做一个实验,将一个容器破坏,让其不可用,然后查看Hystrix的反应,以ola为例。正常情况下,ola的状态是:

23.png

23.png

通过浏览器可以访问ola的API:

24.png

24.png

我们将ola应用在openshift中的路由删掉,让restfulAPI不可访问:

25.png

25.png

然后删除其service:

26.png

26.png

通过浏览器访问API,已无显示:

27.png

27.png

过一会,我们看到ola访问状态已经异常:

28.png

28.png

由于ola是第一个被访问的微服务,因此出现报错:

29.png

29.png

30.png
30.png

查看Hystix,ola微服务其状态已经异常(下图橘黄色的原点,已经熔断)

31.png

31.png

与其它正常的微服务进行状态对比,一看便知:

32.png

32.png

ola微服务被熔断,但这并不影响客户端通过API网关对其他微服务的访问:

33.png

33.png

微服务的分布式追踪

在微服务架构中,我们知道微服务之间主要通过restful API方式相互调用,那么,是否有一种方式,快速追踪微服务之间的API调用,并且通过图形化统一展现呢?

可以通过jaejer实现。在实现环境中,笔者将jaejer部署到一个容器(pod)中:

我们先查看容器,再查看服务:

34.png

34.png

查看jaejer的FQDN:

35.png

35.png

通过浏览器进行访问:

36.png

36.png

追踪API调用:

37.png

37.png

还可以按照不同方式进行排序:

38.png

38.png

例如查看API网关对四个微服务的调用:

39.png

39.png

微服务的统一认证

统一认证(SSO)这不是一个新鲜的词。在微服务架构中,由于微服务的数量较多,进行SSO是很有必要的。

在实验中,笔者使用的keycloak为微服务提供SSO认证。

同样,keycloak也部署在容器中,我们分别查看keycloak的容器、服务和FQDN:

40.png

40.png

通过浏览器可以访问keycloak的FQDN:

41.png

41.png

42.png
42.png

在实验环境中,可以通过页面登录:

43.png

43.png

默认情况下,四个微服务都是未认证的:

44.png

44.png

点击右上角的登录:

45.png

45.png

可以看到微服务处于认证状态(下图ola服务未认证是因为已经被熔断;hola认证时间较长):

46.png

46.png

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

6

添加新评论0 条评论

Ctrl+Enter 发表