微服务数据管理
每个微服务都可以有一个私有数据库来保存需要实现其提供的业务功能的数据。
给定的微服务只能访问专用的私有数据库，而不能访问其他微服务的数据库。
在某些业务场景中，您可能必须为单个事务更新多个数据库。在这种情况下，其他微服务的数据库应仅通过其服务API进行更新（不允许直接访问该数据库）
设计时治理——定义和控制服务创建、设计和实现服务策略
运行时治理——在执行期间执行服务策略的能力
在微服务体系结构中，不需要集中式设计时治理。
微服务可以自行决定其设计和实现。
微服务架构促进了公共/可重用服务的共享
某些运行时管理方面（例如SLA，限制，监视，通用安全要求和服务发现）可以在API-GW级别实现。
服务注册和服务发现
服务注册
Service Registry保存微服务实例及其位置。微服务实例在启动时在服务注册中心注册，在关闭时注销。使用者可以通过service registry找到可用的微服务及其位置
为了找到可用的微服务及其位置，我们需要一个服务发现机制。有两种类型的服务发现机制，客户端发现和服务器端发现。让我们仔细看看这些服务发现机制。
客户端发现在这种方法中，客户端或API-GW通过查询服务注册中心获得服务实例的位置，SpringCloud Eureka 就是典型的客户端发现机制。
在微服务架构方面，微服务的部署起着至关重要的作用，并且具有以下关键要求
能够独立于其他微服务部署/取消部署。
能够在每个微服务级别进行扩展（例如，某个服务可能比其他服务获得更多的流量）
快速构建和部署微服务。
一个微服务中的故障不得影响其他任何服务
Docker 部署，提供了一种很好的方式来部署微服务以满足上述要求。涉及的关键步骤如下
将微服务打包为(Docker)容器映像。 将每个服务实例部署为一个容器。 扩展是基于改变容器实例的数量来完成的。 构建、部署和启动微服务的速度要快得多，因为我们使用的是Docker容器(比普通VM快得多) jenkins +docker进行更快速的自动化构建部署
Kubernetes扩展了Docker的功能，它允许将一组Linux容器作为一个单独的系统来管理，跨多个主机管理和运行Docker容器，提供容器的共存、服务发现和复制控制。正如您所看到的，这些特性中的大多数在我们的微服务上下文中也是必不可少的。因此，将Kubernetes用于微服务部署已经成为一种非常强大的方法，特别是对于大型微服务部署。
利用API安全标准（例如OAuth2和OpenID Connect）为我们的微服务安全问题找到更好的解决方案。在深入探讨这一点之前，让我概述一下每个标准的目的以及如何使用它们。
OAuth2-是访问委派协议。客户端通过授权服务器进行身份验证，并获得一个不透明的令牌，称为“访问令牌”。访问令牌的用户/客户端信息为零。它仅具有对只能由授权服务器检索的用户信息的引用。因此，这被称为“参考令牌”，即使在公共网络/互联网中也可以安全地使用此令牌。
OpenID Connect的行为类似于OAuth，但除了访问令牌外，授权服务器还会发布一个ID令牌，其中包含有关用户的信息。这通常由JWT（JSON Web令牌）实现，并由授权服务器签名。因此，这确保了授权服务器和客户端之间的信任。因此，JWT令牌被称为“按值令牌”，因为它包含用户信息，并且在内部网络外部使用它显然是不安全的。
保留对OAuth和OpenID Connect服务器（授权服务器）的身份验证，以便在客户端有权使用数据的情况下，微服务成功提供访问权限。
使用API-GW，所有客户端请求都有一个入口点。
客户机连接到授权服务器并获得访问令牌(通过引用令牌)。然后将访问令牌连同请求一起发送到API-GW。 网关上的令牌转换——API-GW提取访问令牌并将其发送到授权服务器以检索JWT(通过值令牌)。 然后GW将JWT连同请求一起传递给微服务层 JWT包含有助于存储用户会话等的必要信息。如果每个服务都可以理解JSON Web令牌，则您已经分发了身份识别机制，该机制允许您在整个系统中传输身份 在每个微服务层，我们都可以有一个处理JWT的组件，这是一个非常简单的实现。 事务
微服务中的交易支持如何？实际上，支持跨多个微服务的分布式事务是非常复杂的任务。微服务架构本身鼓励服务之间的无事务协调。
在处理微服务上下文中的错误时，有几种常用的模式
在对微服务进行外部调用时，每次调用都配置一个故障监视器组件，当故障达到某个阈值时，该组件将停止对服务的任何进一步调用(触发电路)。在一定数量的请求处于打开状态(您可以配置)之后，将电路更改回关闭状态
这种模式非常有用，可以避免不必要的资源消耗、由于超时而导致的请求延迟，还可以让我们有机会监视系统(基于主动开路状态)。
