微服务Micro service ,就是将单体应用拆分成多个高内聚低耦合的小型服务，每个小型服务运行在独立的进程，当用户请求API Gateway被路由到下游服务，而服务之间采用轻量级通信机制，独立部署。

文章中去掉了那些细枝末节，比如谁谁在哪年提出的呀等等类似的问题，专注于多个微服务之间的通信，微服务与上层的通信机制。希望会对你有所帮助。

微服务很火，火到人人都在讨论，就好像谁不知道微服务谁就算不上一个合格的程序员一样，而关于微服务的帖子真的是随便一搜一大堆(大多却很相似)，陆陆续续的看了大概一周的微服务+公司的CloudSop总线路由机制的资料，笔者整合了一些比较重要的点，加上一些自己的理解，为小伙伴们总结了一下。

Two pizza principle
如果你问我，微服务到底哪里好？因为他符合著名的两个披萨原则。
这个由亚马逊 CEO JeffBezos 提出的法则，他认为事实并非公司开会参与人数越多越好，他认为人数越多的会议将不利于决策的形成，而是会导致与会人员的人云亦云，称之为两个披萨原则。

JeffBezos把披萨的数量当做衡量团队大小的标准，而在开发过程中亦然，所有参与人从设计、开发、测试、运维所有人加起来 只需要2个披萨就够了。 符合这一法则，微服务变得如此火热也就不那么奇怪了。

为什么使用微服务？

• 单体架构所有功能耦合在一起，开发效率低
• SOA架构的总线模式与某种技术耦合过高
• 轻量级运行时技术的出现(node.js, WAS Liberty等)
• 新的轻量级协议(RESTful API接口, 轻量级消息机制)
• 新的可替代数据持久化模型：如NoSQL, MapReduce, BASE, CQRS等

 

WebUI如何访问这些微服务呢？
在传统的应用之中，我们大多数采取WebUI与后台服务直接进行通信的形式。但现在越来越多的情况下，前台和微服务之间，比如：在淘宝的产品展示界面上，可能会有上百个微服务。虽然允许Web前台向后台同时发送多个请求，但是如果与直接进行通信，那么可能造成前台的代码冗余。并且多个服务可能会经常面临重构，如果前台后台直接进行通信，也不利于后台服务代码的重构。

那么针对这一问题，我们解决的方式是：使用API GateWay作代理。如下图所示：

API Gateway本质上是一个服务器，也就是我们进入后台服务的唯一节点，我们可以理解为一个过渡的中转站。API Gateway封装内部系统的架构，并且提供API给各个WebUI。它负责请求转发、合成和协议转换。这样，所有来自WebUI的请求都要先经过API Gateway，然后路由这些请求到对应的微服务。
API Gateway将经常通过调用多个微服务来处理一个请求以及聚合多个服务的结果。它可以在web协议与内部使用的非Web友好型协议间进行转换，如HTTP协议、WebSocket协议。 反之，API Gateway会暴露一个粗粒度【1】的API给WebUI，API GateWay会调用多个服务，来处理这一个请求，并返回结果給Web UI显示。

参考资料和推荐阅读：
http://dockone.io/article/482https://www.cnblogs.com/wintersun/p/6219259.html

微服务之间如何通信呢？
因为所有的微服务都是独立的Java进程跑在独立的虚拟机上，所以服务间的通行就是IPC（inter process communication 进程间通信），现在基本最通用的有两种方式：

• REST API----Spring Boot)
• RPC----(Dubbo)

无论是REST API 还是RPC，其实都是我们上文讲的API GateWay的一个实现。相比较来讲，REST是基于Http协议的，而RPC(远程过程调用协议)则是一种通过网络从远程计算机程序上请求服务的协议，是基于TCP/IP协议的。HTTP协议是在传输层协议TCP之上的，所以效率来看的话，RPC可能会更胜一筹。

微服务的优缺点：
优点：

• 由于微服务单个模块就相当于一个项目，开发这个模块我们就只需关心这个模块的逻辑即可，代码量和逻辑复杂度都会降低，从而易于开发和维护。
• 微服务架构方式是松耦合的，可以提供更高的灵活性。
• 每个微服务可由不同团队独立开发，互不影响，加快推出市场的速度。
• 技术栈不受限：比如订单微服务和电影微服务原来都是用Java写的，现在我们想把电影微服务改成Nodejs技术，这是完全可以的，而且由于所关注的只是电影的逻辑而已，因此技术更换的成本也就会少很多。

缺点：

• 运维要求高：
  对于单体架构来讲，我们只需要维护好这一个项目就可以了，但是对于微服务架构来讲，由于项目是由多个微服务构成的，每个模块出现问题都会造成整个项目运行出现异常，想要知道是哪个模块造成的问题往往是不容易的，因为我们无法一步一步通过debug的方式来跟踪，这就对运维人员提出了很高的要求。
• 接口调整成本高：
  比如，用户微服务是要被订单微服务和电影微服务所调用的，一旦用户微服务的接口发生大的变动，那么所有依赖它的微服务都要做相应的调整，由于微服务可能非常多，那么调整接口所造成的成本将会明显提高。
• duplicated code：
  对于单体架构来讲，如果某段业务被多个模块所共同使用，我们便可以抽象成一个工具类，被所有模块直接调用，但是微服务却无法这样做，因为这个微服务的工具类是不能被其它微服务所直接调用的，从而我们便不得不在每个微服务上都建这么一个工具类，从而导致代码的重复。

 

以微服务的概念来理解CloudSop平台的总线路由机制
CloudSOP是支撑ICT融合管理的Web云架构平台 。我们主要关注的是CloudSop总线服务的路由机制。有几个主要的概念：ER、IR、BER，这三个概念可以让我们刚好结合着微服务中的API GateWay来理解。
接下来，我们从最简单，最基本的机制，结合上文的API GateWay来深入了解ER、IR、BER的概念。如图所示：

首先来看ER，ER(ERService)是外部接入路由，ER负责将外部请求代理到后端服务。这也就是对应着刚刚讲解的APIGateWay,ER的作用就是将WebUI的多个请求通过ER路由到我们对应的的IR。

再来看IR(BusService) ，用于后端服务间路由转发。在总线路由机制中，IR负责将ER分发过来的请求，继续进行转发给对应的app(后端服务)。IR相当于内部路由,而ER相当于外部路由。
此外，由于不同的App可能部署在不同的服务器上，他们之间构成一个域，由一个，或者多个IR来分发路由，所以当我们需要跨域进行转发请求的时候，就要用的我们的BER啦！
BER：后端服务间路由服务，负责在跨region(域)等场景下的路由。

关于CloudSop总线服务的小总结：
ER,IR,BER也就是实现微服务中的API GateWay的功能，在底层，他们就是一个个ngnix【2】服务，由于他们对外开放端口和安全配置不一样，所以对应的功能也就有些差别，但是通过三者的配合，才可以实现WebUI的请求转发到后台具体的APP服务上。

微服务的开发框架：

• Spring Cloud：http://projects.spring.io/spring-cloud（现在非常流行的微服务架构）
• Dubbo： https://dubbo.incubator.apache.org/
• Dropwizard： http://www.dropwizard.io（关注单个微服务的开发）

---

附：
文章中出现的一些大家可能不太理解的名词，为小伙伴们在这里进行总结。

什么是粗粒度？
说白了粗粒度就是大局上看，细粒度就是更关注于细节。具体的话，个人理解就是，粗粒度和细粒度的区别主要是出于重用的目的,比如说类的设计，为尽可能重用,所以采用细粒度的设计模式，将一个复杂的类(这里就是粗粒度)拆分成高度重用的职责清晰的类（这就是细粒度）。而对于数据库的设计，原责：尽量减少表的数量与表与表之间的连接,能够设计成一个表的情况就不需要细分，所以可考虑使用粗粒度的设计方式。

什么是nginx？
Nginx 是俄罗斯人编写的十分轻量级的 Http 服务器,使用C语言开发，是一个高性能的Http和反向代理服务器，同时也是一个 IMAP/POP3/SMTP 代理服务器。Nginx 以事件驱动的方式编写，所以有非常好的性能，同时也是一个非常高效的反向代理、负载均衡的服务器。

什么是松耦合？
耦合就是指软件组件之间的依赖程度。简单的理解就是：一个服务没有另一个服务就没办法运行，那么就是紧耦合。反之，这个服务并不依赖于其他服务而存在，则是松耦合。

 

如小伙伴们有自己的独特见解，也可以在下方评论留言哈~