前言

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

微服务的概念

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

什么叫单体易用？简单理解就是通过一个单一应用实现若干业务功能模块。目前大多数应用都是单体应用。如: 在银行中，如网银（它本身就是三层架构，有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：

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

查看容器（pod）：

查看应用：

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

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

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

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

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

（1）Hola

（2）Bonjour

（3）Aloha

（4）Ola

微服务的API网关

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

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

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

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

在实验中，笔者通过容器实现API网关：

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

最后查看API网关的FQDN：

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

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

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

微服务的容错处理

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

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

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

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

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

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

先查看Hystrix容器（pod），再查看应用：

查看应用的FQDN：

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

在本实验中，Hystrix已经集成：

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

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

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

然后删除其service：

通过浏览器访问API，已无显示：

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

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

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

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

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

微服务的分布式追踪

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

可以通过jaejer实现。在实现环境中，笔者将jaejer部署到一个容器（pod）中：

我们先查看容器，再查看服务：

查看jaejer的FQDN：

通过浏览器进行访问：

追踪API调用：

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

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

微服务的统一认证

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

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

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

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

在实验环境中，可以通过页面登录：

默认情况下，四个微服务都是未认证的：

点击右上角的登录：

可以看到微服务处于认证状态（下图ola服务未认证是因为已经被熔断；hola认证时间较长）：