关于微服务、ESB、APIGetway 微服务基本概念解释 ESB基本概念解释缺点 API Getway基本概念解释
微服务 基本概念
微服务是SOA（面向服务）下的最终产物，该架构的设计目标是为了肢解业务，使得服务能够独立运行。
解释官方的解释：微服务把一个大型的单个应用程序和服务拆分为数十个的支持微服务。一个微服务的策略可以让工作变得更为简便，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。
通俗的解释：微服务就是把一个整体的系统业务，拆分成原子化的、可独立部署的模块。
例子：比如我有一个OA系统，有C#MVC的网页版和QT的客户端版。现在我要查看一个订单，如果不用微服务，那么代码可能是这么写的：“网页版先写一个查看的方法，客户端版再写一个查看的方法”。这两种方法的逻辑几乎一模一样，但是却要写两遍，再以后的维护上很是麻烦。那么是否有办法解决这个问题呢？
答案自然是有的，我们可以用Python（其他语言也行，这里是举个例子）单独创建一个项目，部署在一台服务器上，并且写一个接口返回查看的数据，让网页版和客户端版通过某种方式（比如http）访问这个接口，获得返回的数据（一般可以是json或者xml）。
按照这种思路，C#MVC的网页版和QT的客户端版都用的同一种方式查看订单，以后如果有修改，只要修改关于查看订单的方法就好了。
微服务的好处只有方便修改么？当然不是！继续刚才的例子，如果用户访问量上来了，那么查看订单的方法的访问量可能很多，而修改账号的可能很少，如果按照最初的思想，修改账号和查看订单是同一个项目，想多部署几台服务器做负载均衡的话，就要同时把两个功能一起负载均衡了。而使用了微服务，查看订单和修改账号是不同的项目，可以单独做负载均衡。
ESB是一种在松散耦合的服务和应用之间标准的集成方式
一般来说，ESB本身的模型就是管道和过滤器。管道就是各种传输和消息传递。各种中介处理，就是过滤器。可以比拟成自来水管和各种阀门的关系
简单来说，ESB就是给各自为政的微服务们创造了一个中心化的政府
解释接着微服务继续讲，我们已经将查看订单的功能分离了出来，成为了一个服务。但当我们把查看订单、账号管理、流程管理、请假申请、在线聊天…等几十个功能全都分离出来时，会发生什么呢？
举个例子：
服务之间的关系变成了这样：
我们发现按照正确地格式调用服务成为了一件难题，怎么办呢？
我们可以用一个“总线”，设计一个严格的约束，来把各个服务链接起来，就如同计算机硬件中的“总线”一样。
你想查看订单？好！去找ESB！你想在线聊天？好！去找ESB！你想管理账号？好！去找ESB！
使用了ESB后，之前的表格就变成了这样的
目的操作查看订单通过规定的格式，与ESB交互在线聊天通过规定的格式，与ESB交互账号管理通过规定的格式，与ESB交互。。。通过规定的格式，与ESB交互现在看起来就舒服多了：
1、等于是把整个系统穿了起来，如果ESB出了问题，整个系统可能无法正常运作。
2、集中化的管理可能带来性能上的瓶颈
3、让微服务的轻便性大大降低
API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。
解释先来看一个表
区别ESBAPI Getway登录态需要可以不需要传输方式各种各样通常为JSON约束有严格的契约文件约束文档约束通信双方交互性双方互相约定，既提供服务又进行消费服务提供方在网关的标准之上建立标准，双方无交互简单来说，APIGetway比ESB更加轻便，内部耦合性更低，并且不需要登录态（ESB在企业内部使用，想要调用任一服务，都需要登录态）
优点：
1、客户端只需要与网关交互即可，网关负责将请求转换成对应的格式，做了一个“矮小的萝莉”的工作
2、APIGetway可以为每一类客户端提供了特定的API，这减少了客户端与应用程序间的交互次数，还简化了客户端代码