简介：上一篇介绍了微服务与单体架构的区别、微服务设计、消息传递、服务间通信、数据去中心化。本文将继续深入微服务并介绍其他特性。治理权力下放通常“治理”意味着构建计划并迫使人们努力工作以实现组织目标。SOA治理指导开发人员开发可重用的服务以及随着时间的推移应如何设计和开发服务。治理在服务提供者和消费者之间建立服务协议，告诉消费者他们可以从提供的服务中获得什么样的支持。SOA中有两种常见的治理类型：设计时治理-定义和控制服务创建、设计和服务策略的实施。运行时治理——确保执行过程的策略。那么治理在微服务中意味着什么？在微服务架构中，不同的微服务相互独立，基于不同的平台和技术。因此，没有必要为服务的设计和开发定义一个通用的标准。微服务的治理去中心化总结如下：微服务架构在设计时不需要关注治理。每个微服务都可以有独立的设计和执行决策。微服务架构侧重于促进通用/可重用服务。运行时治理，例如安全级别保证(SLA)、节流、监控、安全和服务发现，可以在API网关层处理。服务注册与发现在微服务架构下，有大量的微服务需要处理。由于微服务的快速敏捷发展，它们的位置可能会动态变化。因此，需要能够在运行时发现服务所在的位置，而服务发现可以解决这个问题。服务注册注册中心有微服务的实例和位置信息。微服务启动时向注册中心注册自己的信息，关闭时注销。其他用户可以通过注册中心找到可用的微服务和相关信息。服务发现为了找到可用的服务及其位置信息，需要一种服务发现机制。有两种发现机制，客户端发现和服务器端发现。客户端发现-客户端或API网关查询服务注册表或服务的位置信息。图9：客户端发现客户端/API网关必须调用服务注册组件来实现服务发现的逻辑。服务器发现-客户端/API网关向具有已知位置信息的组件（例如负载均衡器）发送请求。组件去注册中心查找微服务的位置信息。图10：服务器端发现像Kubernetes(http://kubernetes.io/v1.1/docs/user-guide/services.html)这样的微服务部署解决方案提供了一种自动的服务器端发现机制。部署微服务的部署方式也很重要。以下是关键：独立于其他微服务发布或取消发布的能力微服务可以水平扩展（一个服务比其他服务请求更多）微服务之间快速构建和发布功能互不影响可以辅助开发和运维在容器中运行应用）可以快速部署微服务，包括要点：将微服务打包成Docker镜像启动容器实例变更实例数量满足扩容需求。与传统的虚拟机模型相比，使用docker容器构建、发布、启动微服务会变得非常快。通过Kubernetes，可以进一步扩展Docker的能力，从单一的linux主机到linux集群，支持多主机，管理容器位置，服务发现，多实例。这些是微服务需求的重要特征。因此，使用Kubernetes来管理微服务和容器的发布是一个非常强大的解决方案。图11：用于构建和部署服务的容器图11显示了零售应用程序的微服务部署。每个服务都在一个独立的容器中，每台主机有两个容器，可以通过kubernetes随意调整容器的数量。安全性在实际运行环境中，微服务的安全性也非常重要。我们先来看看单体架构下安全是如何实现的。对于一个典型的单体应用，安全问题主要是“谁来调用”、“调用者可以做什么”、“如何处理”。服务器收到请求后，一般处于处理链的最前端，通过安全组件对请求信息进行安全处理。是否可以直接将这种处理方式应用到微服务架构中呢？答案是肯定的，我们需要购买一个微服务实现一个安全组件，从资源中心获取相应的用户信息，实现安全管控。这是一种比较初级的方法。可以尝试采用一些标准的API方式，比如OAuth2、OpenID。在深入研究之前，概述一下这两种安全协议及其使用方式会很有帮助。OAuth2-是一种访问委托协议。需要获取权限的客户端向授权服务申请访问令牌。访问令牌没有关于用户/客户端的任何信息，它只是供授权服务器使用的用户参考。因此，这个“引用令牌”也不存在安全问题。OpenID类似于OAuth，但除了accesstoken之外，授权服务器还会颁发一个包含用户信息的IDtoken。通常由授权服务器以JWT（JSONWebToken）的形式实现。这样就保证了客户端和服务器之间的相互信任。JWTtoken是一种“有内容的token”，里面包含了用户的身份信息，在公共环境下使用是不安全的。现在让我们看看如何应用这些协议来保护在线零售网站中的微服务。图12：通过OAuth2和OpenID解决安全问题如图12所示，是实现微服务安全的关键步骤：所有的授权都是由授权服务器通过OAuth和OpenID来实现的，保证用户可以访问到正确的数据。使用API??网关方式，所有客户端请求都有一个***入口。客户端通过授权服务器获取访问令牌，并将令牌发送给API网关。网关处理token-API网关获取到token后，发送给授权服务器获取JWT。网关将JWT连同请求一起发送到微服务。JWT包含必要的用户信息。如果每个微服务都可以解析JWT，那么你系统中的每个服务都可以处理身份相关的业务。在每个微服务中，都可以有一个处理JWT的轻量级组件。事务如何支持微服务中的事务？事实上，跨多个微服务的分布式事务支持是非常复杂的。微服务的设计思想是尽可能避免多个服务之间的事务操作。解决方案是微服务的设计需要遵循功能自包含和单一职责的原则。支持跨多个微服务的分布式事务在微服务架构中并不是一个好的设计思路，通常需要重新定义微服务的职责。在某些场景下，需要支持跨服务的分布式事务，可以在每个微服务内部使用“组合操作”。最关键的是要按照单一职责的原则来设计微服务。如果一个服务不能正常执行某些操作，那么这个服务就有问题。那么上游操作需要在各自的微服务中进行回滚操作。容错设计微服务架构引入了比单体设计更多的服务，增加了每个服务级别出错的可能性。一个服务可能会因为网络问题、底层资源等各种问题而失败，某个服务的失败不应该影响整个应用的崩溃。因此，微服务系统必须具备容错能力，甚至可以在客户端不知情的情况下自动回复。任何服务随时都可能出现问题，监控系统需要能够发现问题并自动恢复。微服务环境中有许多常见的模式。当微服务中的请求失败率达到一定程度后，系统中的监控可以激活断线。当正常请求数恢复到一定水平后，关闭线路中断开关，使系统恢复正常状态。这种模式可以避免不必要的资源消耗，请求的处理延迟会导致超时，从而使监控系统更加完善。防火墙一个应用会有很多微服务，单个微服务的故障不应该影响到整个系统。防火墙模式强调服务的直接隔离，微服务不会因为其他微服务的故障而受到影响。处理超时超时机制是在确定不会再有响应时，主动放弃等待微服务的响应。这个超时应该是可配置的。在什么情况下，如何使用这些模式？在大多数情况下，它应该在网关处处理。当微服务不可用或不回复时，网关可以决定是否执行断线或启动超时机制。防火墙机制同样重要。网关是所有请求的最终入口。一个微服务的故障不应影响其他微服务。网关也是获取微服务状态和监控信息的中心。微服务、企业集成、API管理我们已经讨论了微服务的架构和各种特性，以及它们如何应用于现代IT系统。同样重要的是要认识到微服务并不是解决所有问题的灵丹妙药。一味追求流行的技术概念并不能解决企业IT系统的问题。微服务有很多优势，但是单靠微服务并不能解决企业IT中的所有问题。比如微服务需要去掉ESB，但是在现实的IT系统中，大量的应用和服务都是基于ESB而不是微服务的。要集成现有系统，需要一些集成总线。事实上，微服务与其他企业架构共存。微服务实战：从架构到发布（一）原作者：KasunIndrasiri，软件架构师，WSO2原文链接：https://dzone.com/articles/microservices-in-practice-1译自MaxLeapTeam_Cloud服务开发成员：Frank秦关于MaxLeapMaxLeap移动云服务平台为企业提供一站式的移动研发和运营云服务，帮助企业快速开发和上线移动应用。平台提供数据云存储、云引擎、支付管理、IM、数据分析和营销自动化等服务。官网链接：https://maxleap.cn
