微服务的演变以及微服务与微服务之间的通信

微服务雏形得形成

首先大家看看四个图：

一、单体架构图：

这个图不是微服务内容的一个图，相当于它就是一个系统。这个系统包含了6个模块。
第一个是乘客：PASSENGER MANAGEMENT 第二个是出租车司机：DRIVER MANAGEMENT。
第三个是定位：TRIP MANAGEMENT 第四个是通知：BILLING。
第五个是跟踪：NOTIFICATION 第六个是身份认证：PAYMENTS。

下面的图就好比前身的滴滴打车的项目，最前期的一个图。滴滴刚开始做的时候也是一个单体的架构。并没有想到自己做那么大，只是一个单体的项目。单体的项目设计主要是它把所有的模块融入到一个系统里面去进行实现。这么多的模块共享了一个数据库，针对现在滴滴打车，滴滴公司越来越大，用户的群体也越来越大。一个数据库肯定做不了。它必须在数据库这块做相应的集群，做相应的负载等等做一些相关的操作，现在的滴滴如果用一个数据库的话，做起来非常的困难，这就是单体架构瓶颈的问题，在架构中我们是无法去解决它。

在往下面看的话：PASSENGER:是个乘客，DRIVER:是个司机，比如说乘客下了一个订单，然后这个司机和乘客调用的是同一个RESTAPI，通过rest方式提供的API。我知道这个API，就知道了调用哪个模块了。REST API没有任何的隐蔽性，针对于安全来说是无法做到的，这里没有提供任何网关的形式的。如果通过网关的话，可以分发出额外的连接出来。在这里，以后出现很多的种类的话，这里必须出现问题，所以这里必须要负载均衡，因为所有的连接是由这6个模块所发出来的。并不是通过一个统一的消息总线对RESTAPI的管理。

在往下走这里有一个WEB UI 有一个PC端。这个PC端没有去分哪个用户群体。没有定制化的UI给大家呈现出来，比如是出租车的，司机的，它是一个综合的。所以说这种扩展性就不是很方便。比如说这个出租司机觉得用这个api不太很好，我想统一换一个UI，换完UI的话，就会发现用户端的UI也换掉了。所以说这时就不方便我们去扩展，伸缩性也非常的低。
在往下面都剩下的三个都是从6个模块衍生出来的，是一样的。
在这里插入图片描述
那么微服务是什么呢？

不是我们做项目一开始就能搭建出来一个微服务，现在的微服务基本都是由一个项目拆分而来的。比如说上面的6个模块就是6个不同的子系统。我们可以把这6个子系统就可以看成6个单独的应用/组件。相当于服务即组件的说法，相当于一个组件是由一个团队，一个团队单独的开发和维护的。一说，我们如果要做微服务的话，这套系统必须是复杂的系统才能去应用这套微服务架构。如果做一个简单的系统，比如就两三个业务功能的话，没有必要把它拆分成微服务，后面如果没有多大变化的话，也没有必要搞成微服务。所以说微服务是针对一些复杂的项目来说的，做成一个一个的组件，就是一个一个的服务应用，给我们的客户端提供相应的服务就行了，微服务项目基本上根据用业务的原则来拆分的。比如说上面的单体架构就是6个业务。我就可以把这6个业务可以看成6个独立的子系统，可以部署到6个节点的机子上。

所以微服务的概念就出来了：就是能够用于独立的部署的这样的一个应用，一个应用就是一个服务。他们之间是使用rest风格的api来通信的。下面的图片就是拆分之后按照微服务的方式来拆分的。

二、服务化状态改变图：
这样的通信的架构图，我们把上面的6个子系统，把它拆分成6个服务，他们各个服务之间是使用rest风格的方式来进行通信的，每一个服务都是一个单独的应用，对应的是单独的数据库。对应的是单独的负载均衡服务器，对应的是单独的缓存服务器。在开发中服务与服务之间没有任何的直接联系的。是面向服务的架构。PASSENGER的WEB UI和DRIVER WEB UI是前端的服务。下面的架构图是需要8个团队来开发。可以算成分布式的衍生,也可以算是分布式上的SOA服务化的操作的。原先的服务是通过rpc进行通信的。而现在的风格是通过rest风格的方式来通信和调用的，所有的用户出口，特别是移动端的这边有一个API GATEWAY，叫做API的网关，好比一个路由器，好比家里安了一个宽带，原有的是拨号上网的，现在不需要拨号。只需要在路由器里面去设置不同的网关，或者通过一个网关去动态的分发不同的IP地址，这就可以很好的去隐藏外网的IP地址，所以说这里就比较安全了，不会直接知道服务的IP的，而是通过网关去访问，然后去映射到服务的IP地址上的。然后下面的图中有两个WEB UI，相当于是定制化的。分别给乘客和出租司机定制了一个UI，虽然都是PC端发出来的，不同的身份，进入的是不同的UI服务，这相当于是专人干专事。比较专业就做哪个服务，这就是项目组和项目组之间的耦合度降了很低。
在这里插入图片描述
三、负载均衡图（LOAD BALANCER）：

我们的微服务实例最终会部署到docker容器上的。下面的图中就有很多的docker容器，每一台的docker容器上面部署了对应的跟踪的微服务实例，上面的服务是跟踪的服务。所以说所有的微服务实例都应该部署到docker容器上面去的，通过负载均衡的策略来做负载均衡，通过不同的docker容器去访问不同的微服务实例，首先会找到可用的服务，通过一定的负载均衡的规则去筛选出我们到底定位到哪一个访问的微服务实例，然后再访问进来就可以了。负载均衡的时候，数据是共享的。因为每一个服务，对应一个数据库，每一个服务对应多个微服务实例。相当于多个微服务实例对应一个数据库。
在这里插入图片描述
四、服务与数据库的对应关系图：

下面的图是三个微服务，一个服务就对应一个数据库，对应的就是一个数据库的适配器，后期当写分布式的时候会写如何解决session共享的问题，单点登录也会在分布式的时候会写，这些问题都会出现的自然就会有解决方案。下面的是对应的三个微服务，每个服务对应一个专有的数据库。每个微服务都会做自己的事。比如PASSENGER，通过rest风格的方式先定位，然后这个乘客下了一个订单，下完单子，然后这个出租车司机就可以看到这个订单，然后司机就可以在附近的话就可以抢。所以三个服务之间还是要通信的。
在这里插入图片描述
总结：
是由一个单体应用慢慢的拆分成一个服务的实例，然后每一个服务实例最终都会部署到docker容器上面，原来是部署到本地的，通过脚本部署到tomcat上面，内置的tomcat把它发不出来就可以了。现在基本上是放到 docker容器上面的，每一个服务对应一个团队，每一个服务可以单独部署的，单独的开发，单独的对应一个数据，微服务即组件(完全的模块化，一个模块一个项目，完全松耦合，它们之间就是通过restAPI管理的)，服务服务之间不会去共享common,api,domain。微服务之间只有单独的服务，没有单独的模块提供api。