从一个实验看微服务架构---不谈理念讲干货
Posted 大魏分享
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了从一个实验看微服务架构---不谈理念讲干货相关的知识，希望对你有一定的参考价值。
前言：
本文在书写过程中，参考了大量文档，如《Spring Cloud与Docker微服务架构实战》周立著、红帽Openshift官方技术文档、Openshift社区相关文档。笔者在实验研究过程中，请教了红帽技术专家淡成，在此特别表示感谢。本文在书写过程中，也引用了互联网的一些概念描述，文章最后会列出参考文献链接。
由于篇幅有限，本文只先通过一个实现，简单介绍微服务的整体概念，如果时间允许，后续会分享更多此类文章。
微服务的概念
微服务的架构是针对传统单体应用而言的。
什么叫单体易用？简单理解就是通过一个单一应用实现若干业务功能模块。目前大多数应用都是单体应用。如: 在银行中，如网银（它本身就是三层架构，有web、App、DB），柜面，二代支付，它们虽然都是独立的应用，通过ESB互通并访问核心银行系统，但每个应用内部，都有很多功能模块。
单体应用有很多好处，如易于部署、测试便捷、运维方便。但随着业务需求不断增加，单体应用的代码被“修修补补”，往往变得异常庞大，复杂度越来越高、扩展能力变差。到最后的结果可能就变成这个庞大的应用“牵一发而动全身”，没人敢动、没人敢改，最终阻碍了技术创新。
就如下图这位仁兄，虽然重装备在手，失去了战斗力：
那么，针对这种情况，我们如何能给应用“瘦身”，或者说解决单体应用的问题呢？这就需要了解微服务的架构。
微服务就是将一个单一应用开发为一组小型服务的方法，每个服务是独立运行的进程，服务之间采用轻量级通讯机制。说简单点，就是一拆多。
犹如下图，通过类似“小型特种部队”的方式，每个队员各司其职、整体协作，高效完成战斗任务。
微服务架构中最为关键的一点是：每个微服务都可以用不同的语言开发，使用不同的存储技术。例如在一个特种部队中，有用狙击枪的，有用冲锋枪的。每名队员各有所长、各司其职、人尽其用，从而达到1+1>2的效果。
微服务架构中，每个微服务可独一运行、可独立开发、微服务之间使用Restful API进行通讯等。微服务好处很多：易于开发和维护、启动快、扩展性强等等。当然，它也有挑战：运维要求高、分布式系统复杂度增加等。
微服务的架构与适用平台
微服务的架构有很多，如Dubbo（阿里巴巴微服务架构）、Dropwisard、Armada等。当然，最出名的还是Spring Cloud。
微服务可以运行子在很多平台上，如物理机+Linux、虚拟化+Linux，但微服务由于其本身的特点，更适合于运行在容器上。而Gartner的调查报告，容器主要适用于四种大的场景：
§ 敏捷开发（Developer workflow）
将容器应用于开发场景，也是容器最常见的应用场景。容器的轻量级很适合于开发人员提高开发效率。并且有助于构建持续集成和基础部署架构。
§ 批量运算（Batch computing）
批量运算如HPC、数据分析类的应用，或者高并发、短生命周期的应用。
§ PaaS或类PaaS服务
PaaS，也就是平台即服务。相比于虚拟机，容器显然更适合PaaS。如OpenShift是典型的利用容器提供PaaS的方案。
§ 微服务
微服务架构是一种特定的软件应用程序设计方式——将大型软件拆分为多个独立可部署服务组合而成的套件方案。容器的自身特点使它更适合微服务。
从实验入手--实验环境介绍
接下来，我们看一个通过容器实现微服务的实验。
本实验基于Opeshift容器云平台构建。笔者在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认证时间较长）：
参考文献：
https://cdn.rawgit.com/redhat-helloworld-msa/helloworld-msa/master/readme.html
http://www.infoq.com/cn/articles/construct-micro-service-using-api-gateway
以上是关于从一个实验看微服务架构---不谈理念讲干货的主要内容，如果未能解决你的问题，请参考以下文章