微服务实战：从架构到发布（二）

引言：上篇文章介绍了微服务和单体架构的区别、微服务的设计、消息、服务间通讯、数据去中心化，本篇会继续深刻微服务，介绍其它特性。

治理去中心化

一般“治理”的意思是构建方案，而且迫令人们经过努力达到组织的目标。SOA治理指导开发者开发可重用的服务，以及随着时间推移，服务应该怎么被设计和开发。治理创建了服务提供者和消费者之间对于服务的协定，告诉消费者能从服务提供获取到什么样的支持。

SOA中有两种常见的治理：

• 设计时的治理-定义和控制服务的建立、设计和服务策略的实施。

• 运行时的治理-确保执行过程的策略。

那么微服务中的治理是什么意思呢？

在微服务架构中，不一样的微服务之间相互独立，而且基于不一样的平台和技术。所以，没有必要为服务的设计和开发定义一个通用的标准。

总结微服务的治理去中心化以下：

• 微服务架构，在设计时不须要集中考虑治理。

• 每一个微服务能够有独立的设计、执行决策。

• 微服务架构着重培养通用/可重用的服务。

• 运行时的治理，好比安全级别保证（SLA），限制，监控，安全和服务发现，能够在API网关层处理。

服务注册和发现

微服务架构下，有大量的微服务须要处理。因为微服务的快速和敏捷研发，他们的位置可能会动态变化。所以在运行时须要可以发现服务所在的位置，服务发现能够解决这个问题。

服务注册

注册中心有微服务的实例和位置信息，微服务在启动时向注册中心注册本身的信息，关闭时注销。其它使用者可以经过注册中心找到可用的微服务和相关信息。

服务发现

为了能找到可用的服务和他们的位置信息，须要服务发现机制。有两种发现机制，客户端发现和服务端发现。

客户端发现 - 客户端或者API网关经过查询服务注册中心或者服务的位置信息。

图9：客户端发现

客户端/API网关必须调用服务注册中心组件，实现服务发现的逻辑。

服务端发现 - 客户端/API网关把请求发送到已知位置信息的组件（好比负载均衡器）。组件去访问注册中心，找到微服务的位置信息。

图10：服务端发现

相似Kubernetes（http://kubernetes.io/v1.1/docs/user-guide/services.html ）这种微服务部署解决方案，就提供了服务器端的自动发现机制。

部署

微服务的部署方式也特别重要，如下是关键：

• 可以独立于其余微服务发布或者取消发布

• 微服务能够水平扩展（某一个服务比其余的请求量大）

• 快速构建和发布

• 微服务之间的功能不相互影响

Docker（一个运行在linux上而且开源的应用，可以协助开发和运维把应用运行在容器中）可以快速部署微服务，包括关键几点：

• 把微服务打包成Docker镜像

• 启动容器实例

• 改变实例的数量达到扩容需求

相对于传统的虚拟机模式，利用docker容器，构建、发布、启动微服务将会变得十分快捷。

经过Kubernetes可以进一步扩展Docker的能力，可以从单个linux主机扩展到linux集群，支持多主机，管理容器位置，服务发现，多实例。都是微服务需求的重要特性。所以，利用Kubernetes管理微服务和容器的发布，是一个很是有力的方案。

图11：构建和部署服务的容器

图11，展现了零售应用的微服务部署。每一个服务都在独立的容器中，每一个主机有两个容器，经过kubernetes能够随意调整容器的数量。

安全

在实际运行环境中，微服务的安全也很是重要。咱们先看下单体架构下安全是如何实现的。

一个典型的单体应用，安全问题主要是“谁调用”，“调用者能作什么”，“如何处理”。服务器接收到请求后，通常都在处理链条的最开始，经过安全组件来对请求的信息进行安全处理。

咱们能直接把这种处理方式应用在微服务架构中吗？答案是能够的，须要买个微服务都实现一个安全组件从资源中心获取对应的用户信息，实现安全控制。这是比较初级的处理方式。能够尝试采用一些标准的API方式，好比OAuth2和OpenID。深刻研究以前，能够先归纳下这两种安全协议以及如何使用。

OAuth2-是一个访问委托协议。须要得到权限的客户端，向受权服务申请一个访问令牌。访问令牌没有任何关于用户/客户端的信息，仅仅是一个给受权服务器使用的用户引用信息。所以，这个“引用的令牌”也没有安全问题。

OpenID相似于OAuth，不过除了访问令牌之外，受权服务器还会颁发一个ID令牌，包含用户信息。一般由受权服务器以JWT（JSON Web Token）的方式实现。经过这种方式确保客户和服务器端的互信。JWT令牌是一种“有内容的令牌”，包含用户的身份信息，在公共环境中使用不安全。

如今咱们看下如何在网络零售网站中应用这些协议保障微服务的安全。

图12：经过OAuth2和OpenID解决安全问题

图12中所示，是实现微服务安全的关键几步：

• 全部的受权由受权服务器，经过OAuth和OpenID方式实现，确保用户能访问到正确的数据。

• 采用API网关方式，全部的客户端请求有惟一入口。

• 客户端经过受权服务器得到访问令牌，把令牌发送到API网关。

• 令牌在网关的处理 - API网关获得令牌后，发送到受权服务器得到JWT。

• 网关把JWT和请求一块儿发送到微服务中。

JWT包含必要的用户信息，若是每一个微服务都可以解析JWT，那么你的系统中每一个服务都能处理身份相关的业务。在每一个微服务中，能够有一个处理JWT的轻量级的组件。

事务

在微服务中怎么支持事务呢？事实上，跨多个微服务的分布式事务支持很是复杂，微服务的设计思路是尽可能避免多个服务之间的事务操做。

解决办法是微服务的设计须要遵循功能自包含和单职责原则。跨越多个微服务支持分布式事务在微服务架构中不是一个好的设计思路，一般须要从新划定微服务的职责。某些场景下，必需要跨越服务支持分布式事务，能够在每一个微服务内部利用“组合操做”。

最关键的事情是，基于单职责原则设计微服务，若是某个服务不能正常执行某些操做，那么这个服务是有问题的。那么上游的操做，都须要在各自的微服务中执行回滚操做。

容错设计

微服务架构相比较单体的设计而言，引入了更多服务，在每一个服务级别会增长发生错误的可能性。一个服务可能因为网络问题、底层资源等各类问题致使失败。某个服务的不可能不该该影响整个应用的崩溃。所以，微服务系统必须容错，甚至自动回复，对客户端无感知。

任何服务在任什么时候间都有可能出问题，监控系统须要可以发现问题，而且自动恢复。微服务环境下有很多经常使用的模式。

线路中断

微服务中请求的失败率达到必定程度后，系统中的监控能够激活线路中断。当正常请求的数量恢复到必定程度后，再关闭线路中断的开关，使系统回复到正常状态。

这个模式能够避免没必要要的资源消耗，请求的处理延迟会致使超时，借此能够把监控系统作的更完善。

防火墙

一个应用会有不少微服务租车，单个微服务的失败不该该影响整个系统。防火墙模式强调服务直接的隔离性，微服务不会受到其它微服务失败的影响。

处理超时

超时机制是在肯定不会再有应答的状况下，主动放弃等待微服务的响应。这种超时应该是可配置的。

哪些状况下，如何使用这些模式呢？大多数状况，都应该在网关处理。当微服务不可用或者没有回复时，网关可以决定是否执行线路中断或者启动超时机制。防火墙机制一样重要，网关是全部请求的惟一入口，一个微服务的失败不该该影响到其它微服务。网关也是得到微服务状态、监控信息的中心。

微服务，企业集成，API管理

咱们已经讨论了微服务的架构和各类特性，以及如何应用在一个现代的IT系统中。同时也须要意识到，微服务不是解决全部问题的灵丹妙药。盲目追求流行的技术概念并不能解决掉企业IT系统的问题。

微服务有不少优点，可是仅靠微服务不能解决企业IT中的全部问题。例如，微服务须要去除ESB，可是现实的IT系统中，大量的应用和服务是基于ESB而不是微服务。集成现有的系统，须要一些集成总线。实际状况是，微服务和其它企业架构并存。

---

原文做者：Kasun Indrasiri，软件架构师，WSO2
原文连接：https://dzone.com/articles/microservices-in-practice-1
翻译自MaxLeap团队_云服务研发成员：Frank Qin

关于MaxLeap
MaxLeap移动云服务平台为企业提供一站式的移动研发和运营云服务，帮助企业快速研发和上线移动应用，平台提供数据云存储，云引擎，支付管理，IM，数据分析和营销自动化等服务。
官网连接：https://maxleap.cn