关于分布式、微服务、网关的一些理解

一、微服务和分布式的概念

（1）微服务是架构设计方式
（2）分布式是系统部署方式

二、微服务和分布式的区别

	微服务	分布式
1	微服务架构。这是一种独特的架构设计模式，这个服务可以单独部署运行	服务部署在不同的机器上
2	不同服务之间通过rpc调用	服务之间也是通过rpc来交互或者是webservice来交互的
3	一个服务只提供一个功能	一个服务可以提供一个或多个功能

三、微服务和分布式的关系

系统应用部署在超过一台服务器或虚拟机上，且各分开部署的部分彼此通过各种通讯协议交互信息，就可算作分布式部署，生产环境下的微服务肯定是分布式部署的，分布式部署的应用不一定是微服务架构的，比如集群部署，它是把相同应用复制到不同服务器上，但是逻辑功能上还是单体应用。

四、微服务和网关

（1）微服务
实际上是指微服务架构。这是一种独特的架构设计模式，它将是软件、web或移动应用拆分为一系列独立的服务——如微服务。这些服务仅用于某一个特定的业务功能，例如：用户管理、用户角色、电子商务购物车、搜索引擎、社交媒体登录等。此外，它们是相互独立的，这意味着它们可以采用不同的编程语言和数据存储。微服务中几乎不存在集中管理，它使用轻量级的HTTP、REST或Thrift API来进行内部通信。

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

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

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

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

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

（2）API网关
API网关是一个服务器，是系统的唯一入口（也是微服务领域中重要的组件之一）。

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

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

（3）微服务和API网关的关系
在微服务架构中，有一个组件可以说是必不可少的，那就是微服务网关，微服务网关处理了负载均衡，缓存，路由，访问控制，服务代理，监控，日志等。API网关在微服务架构中正是以微服务网关的身份存在。
目前业界也有多款成熟的API网关可用:Kong、Tyk、Zuul、Traefik、Spring、Cloud Gateway等。

API 网关模式意味着你要把API 网关放到你的微服务们的最前端，并且要让API 网关变成由应用所发起的每个请求的入口。这样就可以明显的简化客户端实现和微服务应用程序之间的沟通方式。就好比乐队有个指挥家，下面一堆人（微型服务）演奏自己的乐器。这个指挥家（API网关）可以以某种方式来协调我们的架构如何处理请求。

以前的话，客户端不得不去请求Customers，然后再到Orders，然后是Invoices。客户端需要去知道怎么去一起来消费这三个不同的service。使用API网关，我们可以抽象所有这些复杂性，并创建客户端们可以使用的优化后的端点，并向那些模块们发出请求。API网关让我们的客户端不用再需要知道和关心模块的地址（address）了。网关负责来搞这些事情，你只需要知道网关就好了。你可以去改变实现而且还可以改变API接口。不过通常来说，你改变接口后，会增加客户端出问题的风险。

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

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

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