分布式系统详解--架构简介（微服务）

分布式系统详解--架构简介（微服务）

       前面的一个集合我们也差不多聊完了整个分布式的基础知识，把基本上包含的内容点也简单做了一下了解和分析，在每一个基础店里面，如果细细探讨和研究，都是至少一本数的技术和含量，而这里只能起到一个抛砖引玉的过程，真正需要详细的看待分布式系统详解中的每一篇基础知识的时候，还是相当的不足。希望起到一个系统的作用，让大家在做分布式的时候有章可循当然欢迎指出错误。今天主要是就现在很火热的微服务来进行一次微微的探讨（最下面有文章快速跳转链接~~）。

一。什么是微服务呢？

      让我们先看一下之前的软件架构风格，Monolithic架构，也叫整体架构。这个比较适合小项目，开发简单、集中管理。缺点一大堆：功能都在本地、开发效率低、代码维护难、部署不灵活、稳定性不高、扩展性极差......

      来看看应运而生的微服务：开发一个单个小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。服务使用HTTP / REST等同步协议或AMQP等异步协议进行通信。也可以说他们可以彼此独立地开发和部署服务。每个服务都有自己的数据库，以便与其他服务分离。说白了：松耦合！！、

让我们来看看微服务示意图，有图才好理解（仔细看你就明白了）。

      再次强调的是，微服务运用了以业务功能的设计概念，应用程序在设计时，就能先以业务功能或流程设计先进行分割。将各个业 务功能都独立实作成一个能自主执行的个体服务，然后再利用相同的协定将所有应用程序需要的服务都组合起来，形成一个应用程序。

二、微服务规划

2.1 数据库

2.1.1 数据库的三种设计模式

（1）每个服务都各有一个数据库，同属性的服务可共享同个数据库。

（2）所有服务都共享同个数据库，但是不同表格，并且不会跨域存取。

（3）每个服务都有自己的数据库，就算是同属性的也是，数据库并不会共享。

2.1.2 数据库的可弃性

      实践微服务架构中有许多的做法。但是其中一种的做法是将数据库视作短期的储存空间而不是长期的资料。因为他们可以在上线时从事件中心回复，因此可以快速的从内存中快速存取（例：Redis）作为数据库服务器。这种做法需要将每个请求当作事件来进行广播，这样就可以从事件存储中心重播所有的事件。

2.2 沟通与事件广播

      在微服务中最重要的就是每个服务相互独立，服务和服务之间不应该有所沟通，如果要进行沟通的话，那就采用异步的方式进行沟通。在这里也是有两种方式：

2.2.1 事件存储中心

这可以让你的服务集群中广播事件，并且在每个服务中监听每个事件并做处理，令这些服务之间没有紧密的连接性，而发生的事件都会被保存在事件存储中心。这就意味着，当微服务重新上线，部署时可以重播所有事件。这造就了微服务的数据库随时可以删除、摧毁、且不需要从其他服务中获取资料。

2.2.2 讯息伫列

这令你能够在服务集群中广播消息，并传递到每一个服务，具有这个功能的有RabbitMQ，或者其他的消息中间件。

2.3 服务探索

       单个服务在上线的时候，会向服务中心注册自己的IP位置、服务内容，如此以来，服务中心不需要向每个微服务表明自己的IP位置，也不用对每个微服务单独设定，当A服务向另一个服务B呼叫的时候，会向服务中心询问B的IP位置，得到位置就可以直接进行呼叫。

      这样就可以统一集中所有服务的位置，并不是分散于每一个服务。还有一个好处，服务探索中心还可以每隔一段时间就向各个服务进行检查，如果这个服务在一定时间内没有回应，那么就可以把这个服务除掉。避免其他服务对他进行呼叫反而得不到响应。

三、微服务架构部署图

      具体如何进行搭建微服务框架，比如说涉及到的Docker容器技术、springboot、SpringCloud技术后面的博客中会一一讲解。从下一章就进行真实的实战部署代码阶段。~~

                                                              参考地址     https://zh.wikipedia.org/wiki/%E5%BE%AE%E6%9C%8D%E5%8B%99