微服务的由来
先给出一个不是微服务的案例：
1.1、上面的就是一个系统，这个系统里面包含了6个模块：乘客，出租司机，定位，通知，跟踪，身份认证。上面的系统有点像滴滴打车项目的前身，前身也是一个单体的项目。单体的项目就是把所有的模块融入到一个系统里面去。这6个模块共享了一个数据库。当滴滴打车的用户群体达到一定程度的话，一个数据库肯定做不了，它必定会在数据库上做相关的集群做相关的负载等等的一些操作，这也不是我们想要的，这就是单体架构瓶颈的地方。
1.2、在往下走passenger是一个乘客，driver是一个司机。比如说乘客下一个订单，然后乘客和司机调用的都是同一个restAPI。知道哪一个API的话就知道调用哪个模块的应用了，它没有任何的隐蔽性，对于安全来说是无法做到的。这里没有提供任何网关的形式，没有通过网关再分发额外的链接出来，然后再去调用相应的模块。比如这里的乘客和司机的人数越来越大的时候，必须在restAPI那块做负载均衡。因为所有的链接都是从这6个模块的应用出来的。并不是通过一个企业消息总线来对RestAPI来控制的。那么这里肯定是不行的。这就是单体架构的。
1.3、在往下走是WEB UI，这里的PC端没有去区分哪个用户的群体。没有定制的UI给呈现出来。这时的扩展性就很小，伸缩性也非常的低。
1.4、STRIPE,SENDGRID,TWILIO：这三个模块就不用看了，都是从6个模块中演变出来的
2、微服务是什么呢？
不是一开始做项目就能够搭建出来一个微服务出来，都是由一个项目拆分出来的。比如现在有一个老的项目，要把它搞成微服务的话，需要进行项目的拆分。把上面的一个一个子模块 ，做成一个一个单独的应用/组件。 微服务做到了服务即组件的说法。相当于一个组件由一个团队单独的去开发和维护。一般是比较复杂的系统才能做成微服务的应用。根据业务来拆分的。可以独立部署在不同的节点机上。一个应用就是一个服务，服务与服务之间通过restAPI进行通信的。
上面的图就是微服务的一个架构图。可以把6个子系统拆成6个服务。之间是通过restAPI来通信的，每个服务都是单独的应用，对应的是单独的数据库，单独的负载均衡服务器，单独的缓存服务器。每一个服务的开发中没有任何的冲突和联系的。
2.1、在用户的接口中有一个API的gateWay，好比有一个路由器，通过网关分发出不同的ip地址。这就很好的隐藏了外网的ip地址。这就很安全了，不会直接知道服务的ip地址的。通过网关去访问，然后去映射到服务的ip上去的。所以那里有一个网关。做成微服务的话，项目与项目之间的耦合性就降低了很多。参考书籍<<架构的未来>>
3、负载均衡的形成：
最终微服务的实例最终会部署在docker的容器的上面。上图有4台docker容器。上面部署了定位的微服务实例。然后通过负载均衡的策略去做负载均衡，来打下不同的docker容器里面，然后通过不同的rest风格的api的方式去定位访问哪一个微服务实例，负载均衡的时候，数据库的信息是共享的。因为每一个微服务对应一个数据库。上面的三个微服务实例对应一个数据库。
4、一个服务对应一个数据库：
上面的乘客也好，出租车司机也好，定位也好都会对应一个数据库。比如一个乘客通过restAPI先定位然后再下一个单子，然后这个司机就可以看到这个订单，然后就会去抢这个订单。实际上这三个服务之间是相互通信的。
总结：上面的就是微服务雏形的形成。由一个单体应用拆分成一个一个微服务的实例。最后每一个为服务器的实例都会部署到docker容器上面。docker可以跑在系统上或者linux上的一个容器。一般是按照系统的业务功能拆分服务，之间只是通过restAPI来通信的。
