微服务架构

官方定义：

The microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services , which may be written in different programming languages and use different data storage technologies.
-- James Lewis and Martin Fowler

这里总结以上特点：

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

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

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

4.服务是独立部署的

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

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

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

如下：

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

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

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

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

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

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

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

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

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

客户端如何访问这些服务？

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

API Gateway的作用如下：
1.提供统一服务入口
2.聚合后台的服务
3.提供监控，安全校验等功能

服务之间如何通信？

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

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

1.REST(HTTP) 2.RPC(Thrift gRpc dubbo) 3.消息队列(异步)

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

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

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

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

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

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