微服务架构学习笔记

**

微服务定义

**
微服务架构（Microservice Architecture）是一种思想，旨在通过将应用程序分解成一套较小的互联服务，以实现对解决方案的解耦。
目的：有效的拆分应用，实现敏捷开发和部署
微服务架构模式相当于此伸缩立方的 Y 轴坐标，此立方是一个来自《架构即未来》 的三维伸缩模型。另外两个坐标轴是由运行多个相同应用程序副本的负载均衡器组成的X 轴坐标和 Z 轴坐标（或数据分区) ，其中请求的属性（例如，一行记录的主键或者客户标识) 用于将请求路由到特定的服务器。

在运行时，X 坐标轴上运行着服务的多个实例，每个服务配合负载均衡器以满足吞吐量和可用性。某些应用程序也有可能使用 Z 坐标轴来进行分区服务。下图展示了如何用 Docker 将 Trip Management 服务部署到 Amazon EC2 上运行。
**

微服务特点

**
1、一些列的独立的服务共同组成系统

2、单独部署，跑在自己的进程中

3、每个服务为独立的业务开发

4、分布式管理

5、非常强调隔离性

微服务实现方式

微服务通常由重写一个模块开始。要把整个巨石型的应用重写是有很大的风险的，也不一定必要。

我们向微服务迁移的时候通常从耦合度最低的模块或对扩展性要求最高的模块开始，把它们一个一个剥离出来用敏捷地重写，可以尝试最新的技术和语言和框架，然后单独布署。 它通常不依赖其他服务。

微服务中常用的API Gateway的模式主要目的也不是重用代码，而是减少客户端和服务间的往来。API gateway模式不等同于Facade模式，我们可以使用如future之类的调用，甚至返回不完整数据。

服务之间通信方式

所有的微服务都是独立的Java进程跑在独立的虚拟机上，所以服务间的通信就是IPC（inter process communication），已经有很多成熟的方案。现在基本最通用的有两种方式：

同步调用：

①REST（JAX-RS，Spring Boot）

②RPC（Thrift, Dubbo）

异步消息调用

①Kafka
②Notify
③MetaQ

同步和异步的区别：

一般同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。RESTful和RPC的比较也是一个很有意思的话题。

一般REST基于HTTP，更容易实现，更容易被接受，服务端实现技术也更灵活些，各个语言都能支持，同时能跨客户端，对客户端没有特殊的要求，只要封装了HTTP的SDK就能调用，所以相对使用的广一些。

RPC也有自己的优点，传输协议更高效，安全更可控，特别在一个公司内部，如果有统一个的开发规范和统一的服务框架时，他的开发效率优势更明显些。就看各自的技术积累实际条件，自己的选择了。

而异步消息的方式在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能保证调用方的服务体验，继续干自己该干的活，不至于被后台性能拖慢。

不过需要付出的代价是一致性的减弱，需要接受数据最终一致性；还有就是后台服务一般要实现幂等性，因为消息发送出于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）；最后就是必须引入一个独立的broker，如果公司内部没有技术积累，对broker分布式管理也是一个很大的挑战。

微服务架构的优点

易于开发和维护

一个微服务只会关注一个特定的业务功能，所以它业务清晰，代码量较少。

单个微服务启动较快

单个微服务代码量较少，所以启动会比较快。

局部修改容易部署

单体应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。

技术栈不受限

在微服务架构中，可以结合项目业务及团队的特点，合理地选择技术栈。

按需伸缩

可根据需求，实现细粒度的扩展。