一遍文章看微服务架构

什么是微服务架构

在理解微服务之前，顾名思义应该从两个方面进行理解，什么是“微”？什么是“服务”？然后再去理解为什么需要用到“微”这个量级，这里就需要结合整个软件架构模式进行演变了；微狭义来讲就是体积小，多小算小？亚马逊认为：由2-Pizza团队端到端负责一个到一组服务，大小是合适的；主要有一下四个特性

1. 粒度小，且专注于一件事；
2. 独立的进程（java的tomcat,nodejs等）；
3. 轻量级通信机制，通常是HTTP/REST(接口）；
4. 松耦合，可独立部署（这点是微服务与单体服务的核心区别）
5. 方便以后项目的新技术扩展

微服务架构的背景：

微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理

微服务的优势是什么?

在讨论微服务的优势之前，这里是将微服务与早期的单体服务进行相关的比较：

1. 更快的上线时间：
   在单体服务时期，如果对系统的部分功能的改动，需要对整个系统进行重新部署，第一部署的时间将大大延长，第二轻微的更改都需要重新部署整个堆栈，从而引入风险性及复杂性；相反微服务的情况下进行修改更新可以立马测试、部署上线，对个别服务的更改不会影响系统其他的部分；
2. 更好的灵活性和可扩展性
   单体服务要求整个系统（及所有功能)同事扩展，而使用微服务，只需要缩放需要额外性能的组件或功能，可以通过部署更多微服务实例来扩展服务范围，从而实现更有效的容量规划并降低软件许可成本，从而降低总体成本；
3. 具有良好的故障弹性：
   使用单体服务时，组件故障可能会危及整个应用程序；在微服务中，每项服务都是隔离的，以防止级联失败导致整个系统崩溃，如果单个微服务的所有实例均失败，则整体服务可能降级，也即出现部分功能崩溃，但是其他组件仍然可以提供有价值的服务；
4. 技术栈不受限
   每个服务都可以根据需求有自己的技术实现方式，及相关技术框架，而上层业务不需要关注服务的底层实现只需要关注与服务之间的通讯即可，这样可以提高某些服务功能的性能从而提升整个系统的性能；

微服务的缺点

1. 运维成本及要求较高
   对于单体架构来讲，我们只需要维护好这一个项目就可以了，但是对于微服务架构来讲，由于项目是由多个微服务构成的，每个模块出现问题都会造成整个项目运行出现异常，想要知道是哪个模块造成的问题往往是不容易的，因为我们无法一步一步通过debug的方式来跟踪，这就对运维人员提出了很高的要求；最终排错可能更加麻烦了，需要较高的运维成本去得知具体哪一环节出错；
2. 分布式的复杂性
   对于单体运用来说，我们可以不适用分布式，但是对于微服务架构来说，分布式几乎是必会用的技术，由于分布式本身的复杂性，导致微服务架构也变得复杂起来。
3. 接口调整成本高
   在调整一个运用层的接口的时候，需要追溯到底层服务的各个接口支撑的相关修改，有依赖他的微服务都要做相应的调整，整个修改就不是很便利，由于微服务可能非常多，那么调整接口所造成的成本较高；
4. 重复劳动
   在单体结构上如果某个方法可以被重复使用，这时我们会将该方法抽象出来作为一个工具类进行使用，但是微服务却无法这样做，因为微服务的工具类不能被其他服务所直接调用，当然有的说可以使用相同的基石框架，然后公用的工具类放在底层基石框架当中，这样最终的结果将造成基石框架越来越复杂，公司其他的业务方可能很多不必要的的东西也将会引用，这样不利于整个框架在公司的全面运行；

微服务的通讯机制：

1. 同步：RPC,REST HTTP等；
   注：此处不要有误解微服务就是采用rpc调用，然后通过zk集群来降低网络时延，这是个很low很可笑的想法，本身rpc和http都是网络调用，只不过两种方式所基于的协议层不一样罢了，rpc是基于TCP/IP协议的，可以进行长连接并且做一定的心跳机制，而http服务主要是基于http协议的，我们都知道http协议是在传输层协议TCP之上的，所以整体效率来看，rpc确实更胜一筹，但他们的本身都是网络调用，所以网络时延总体来说都是一样的，只不过在实现形式上有所变化，而在微服务中大量使用RPC调用这主要是为了提高调用方与服务提供方的研发效率；REST和RPC都常用在微服务架构中：
   ** HTTP相对更规范，更标准，更通用，无论哪种语言都支持http协议，现在开源的中间件，基本最先支持的几个协议都包含RESTful;
   ** RPC框架作为架构微服务的基础组件，他能大大降低架构微服务的成本，提高调用方玉服务提供方的研发效率，屏蔽跨进程调用函数的各类复杂细节，让调用方感觉就像调用本地函数一样调用远程接口，大大简化调用方式而已，并不是说降低网络时延；
2. 异步通信：消息队列。要考虑消息可靠传输、高性能，以及编程模型的变化等；

微服务框架中接口协议的对比

https://www.cnblogs.com/zhaiyf/p/9111159.html