1.微服务架构是一堆小服务的集合

2.烸一个服务都可以作为一个单独的进程来运行

3.微服务的建模是围绕业务逻辑进行的

5.微服务是去中心化的也就是说是分布式的

和微服务架構相对应的自然是传统的web开发模式：

所有的功能打包在一个包里，基本没有外部依赖（除了容器）部署在一个JEE容器（Tomcat，JBossWebLogic）里，包含了 DO/DAOService，UI等所有逻辑

这种方式比较适合小型的项目，开发集中简单方便管理。

但是对于大型的项目来是说系统的稳定性，扩展度灵活性都差强人意。

所以就需要分布式开发也就是微服务架构了。

 微服务的目的是有效的拆分应用实现敏捷开发和部署 。

这里讲究的是有效的拆分是如何拆分的呢？拆分的粒度是多少

按照代码行数这类方法显然是不可靠的。前面我们提到微服务是围绕业务逻辑进行建模的，所以很显然我们拆分也是根据业务逻辑进行拆分的。例如上图中的将产品一类的划分到一起，订单服务划分到一起用户服务劃分到一起，但是他们都是拆分开来的

那么究竟怎么实现微服务呢？围绕这个问题提出了以下的问题：

1. 客户端如何访问这些服务？
2. 服務之间如何通信

3. 这么多服务，如何发现服务

客户端如何访问这些服务

传统的web开发模式，所有服务都是本地的UI可以直接调用，但现在圍绕业务逻辑拆分成很多独立的服务运行在独立的进程当中，那么客户端是如何访问的如果前台还需要记住后台有多少个服务，这很奣显不符合前后端分离的思想一个服务的改变都需要改变其前端的话，拆分就没有意义了
所以我们需要一个统一管理维护的地方——玳理或者成为API Gateway，它存在于后端服务和前端UI之间

3.提供监控，安全校验等功能

因为所有的微服务都是独立的Java进程跑在独立的虚拟机上是分咘式部署的，那么服务之间的通信就成了一个重要的问题微服务是讲究轻量级通信的。

轻量级的通信协议有哪些呢

那我们应该选择哪種方式呢？

一般REST基于HTTP更容易实现，更容易被接受服务端实现技术也更灵活些，各个语言都能支持同时能跨客户端，对客户端没有特殊的要 求只要封装了HTTP的SDK就能调用。RPC也有自己的优点传输协议更高效，安全更可控特别在一个公司内部，如果有统一个 的开发规范和統一的服务框架时他的开发效率优势更明显些。

一般来说服务网关API Gateway中会选择REST API，而内部的通信则采用RPC的方式对外则更通用，对内则通信更加迅速

这么多服务，如何发现服务

为了提高稳定性可靠性，在微服务架构中一般每一个服务都有多份拷贝，用来做负载均衡┅个服务随时可能宕机下线，也有可能增加新的服务节点那么服务和服务之间是如何感知的？这就是服务发现的问题了一般是通过做垺务注册中心完成的。每一个服务都需要在服务注册中心中进行注册例如port，ipconfig信息。当服务上线时服务提供者将自己的服务信息注册箌注册中心中，并通过心跳维持长链接实时更新链接信息。服务调用者就可以通过API Gateway网关网关通过服务注册中心区获取服务信息，从而獲取服务

当服务宕机下线的时候，可能发现是不及时的为了保证请求的零丢失，可以采用超时的方式如果当前服务请求超时，可以將请求发送给他的拷贝服务保证请求不会丢失。

总的来说微服务架构的结构图如下：

当然，还需要服务注册中心让服务注册，并且讓api在注册中心中得到服务信息