微服务

何为微服务

微服务架构是一种将单应用程序作为一套小型服务开发的方法，每种应用程序都在其自己的进程中运行，并与轻量级机制（通常是HTTP资源的API）进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制进行独立部署。这些服务的集中化管理已经是最少的，它们可以用不同的编程语言编写，并使用不同的数据存储技术。

在微服务架构风格中，一个大应用被拆分成为了多个小的服务系统提供出来，这些小的系统他们可以自成体系，也就是说这些小系统可以拥有自己的数据库，框架甚至语言等，这些小系统通常以提供 Rest Api 风格的接口来被 H5, Android, IOS 以及第三方应用程序调用。

但是在UI上进行展示的时候，我们通常需要在一个界面上展示很多数据，这些数据可能来自于不同的微服务中，举个例子。

在一个电商系统中，查看一个商品详情页，这个商品详情页包含商品的标题，价格，库存，评论等，这些数据对于后端来说可能是位于不同的微服务系统之中，可能我后台的系统是这样来拆分我的服务的：

产品服务 - 负责提供商品的标题，描述，规格等。
价格服务 - 负责对产品进行定价，价格策略计算，促销价等。
库存服务 - 负责产品库存。
评价服务 - 负责用户对商品的评论，回复等。

微服务诞生的背景

在开始介绍微服务风格（microservice style）前，比较一下整体风格（monolithic style）是很有帮助的：一个完整应用程序（monolithic application）构建成一个单独的单元。企业应用程序通常建立在三个主要部分中：一个客户端用户界面（由用户计算机上的浏览器中运行的HTML页面和JavaScript组成）数据库（包括插入常见的通常是关系数据库管理的多个表系统）和一个服务器端应用程序。

单体应用程序可以比较容易地构建，而且是以更小的代码库来开始。我们可以在同一个代码库中构建和开发所有内容，这意味着我们不用担心模块化以及如何把不同的组件放在一起来共同工作这些事情。而且测试起来也简单。通常当我们测试一个单体应用时，我们一开始就只面对一个应用，然后测试我们集成的单元测试。我们只需要面对一个应用就够了。而且，很多IDE对单体应用已经支持的非常好了。比如Eclipse围绕着单体应用就提供了很多成熟的测试工具，包括idea也是。

但，随着代码量的急剧膨胀，我们把所有的都放在一个代码库里显然不是一种理想的选择。随着时间的推移，越来越多的功能需要构建进去，代码越来越多，在一个地方跟踪代码将变得更加的困难。

由于这些原因，团队在一个大的代码库上迭代将会变慢。再来说个事情，比如我现在要更换数据库存储方案，或者想要使用一种新的技术。在单体应用中，这样的改动通常是非常痛苦的。

由于上面所有的原因，你开始扩张你的组织。然后发生的事情就是团队内部沟通成本变得更昂贵，因为理解代码库里的代码究竟是干什么的变得更加困难。

这也是微服务诞生所要解决的问题。

API网关

何为API网关

API网关是一个服务器，是系统的唯一入口（也是微服务领域中重要的组件之一）。是大型分布式系统中，为了保护内部服务而设计的一道屏障，可以提供高性能、高可用的 API托管服务，从而帮助服务的开发者便捷地对外提供服务，而不用考虑安全控制、流量控制、审计日志等问题，统一在网关层将安全认证，流量控制，审计日志，黑白名单等实现。网关的下一层，是内部服务，内部服务只需开发和关注具体业务相关的实现。网关可以提供API发布、管理、维护等主要功能。开发者只需要简单的配置操作即可把自己开发的服务发布出去，同时置于网关的保护之下。

简单地说，API网关就是API们的管理者，例如能防止你要开放的API被恶意请求之类的…顺便再加上了一些负载均衡、身份验证的功能。

亚马逊API图：

市面上的API网关工具：

目前业界也有多款成熟的API网关可用:Kong、Tyk、Zuul、Traefik、Spring、Cloud Gateway等等

二者的联系

微服务网关。微服务的概念最早在2012年提出，在Martin Fowler的大力推广下，微服务在2014年后得到了大力发展。 在微服务架构中，有一个组件可以说是必不可少的，那就是微服务网关，微服务网关处理了负载均衡，缓存，路由，访问控制，服务代理，监控，日志等。API网关在微服务架构中正是以微服务网关的身份存在。

Ok，为什么我们需要一个API网关呢？

如图所示，它展示了一个乐队，然后有个指挥家，下面一堆人（微型服务）演奏自己的乐器。这个指挥家（API网关）可以以某种方式来协调我们的架构如何处理请求。

API 网关模式意味着你要把API 网关放到你的微服务们的最前端，并且要让API 网关变成由应用所发起的每个请求的入口。这样就可以明显的简化客户端实现和微服务应用程序之间的沟通方式。

以前的话，客户端不得不去请求Customers，然后再到Orders，然后是Invoices。客户端需要去知道怎么去一起来消费这三个不同的service。使用API网关，我们可以抽象所有这些复杂性，并创建客户端们可以使用的优化后的端点，并向那些模块们发出请求。

API网关让我们的客户端不用再需要知道和关心模块的地址（address）了。网关负责来搞这些事情，你只需要知道网关就好了。你可以去改变实现而且还可以改变API接口。不过通常来说，你改变接口后，会增加客户端出问题的风险。

使用API网关后，你可以在单独的层上有效地抽象，这样你就可以更改实现和接口，同时保持现有客户端的公共接口相同。这意味着你总是可以做一些调整的事情。

API网关对于那些从单体转变到微服务的应用来说也是一个非常有帮助的工具。如果你现在维护一个单体应用，你就可以把一个API网关放到这个单体的最前面，然后你就慢慢地开始把单体拆分成很多的不同的微服务，在这个过程中，客户端就一直是通过API网关来保持自己的运作，这样让你的迁移过程更优雅！

API网关将随着时间的推移实现和消费后端的上游service，同时保持客户端的正常工作。拥有一个API网关可以帮助我们实现这样的过渡。