微服务

 

一、相关文档

简单的例子入门：https://www.zhihu.com/question/65502802

微服务的发展历史：https://blog.csdn.net/xxxlllbbb/article/details/105107628

单体应用于微服务的对比：https://blog.csdn.net/qinaye/article/details/82840625

serverless无服务的发展史和理解：https://www.jianshu.com/p/c972a383c132

serverless无服务详解：https://www.cnblogs.com/tugenhua0707/p/10991363.html

 

二、学习笔记

1. 微服务的前身——单体应用
   一个归档包（可以是JAR、WAR、EAR或其它归档格式）包含所有功能的应用程序，通常称为单体应用。而架构单体应用的方法论，就是单体应用架构。

   1. 优点

   • 便于共享：单个归档文件包含所有功能，便于在团队之间以及不同的部署阶段之间共享。
   • 易于测试：单体应用一旦部署，所有的服务或特性就都可以使用了，这简化了测试过程，因为没有额外的依赖，每项测试都可以在部署完成后立刻开始。
   • 易于部署：只需将单个归档文件复制到单个目录下。

   2. 缺点

   • 复杂性高：由于是单个归档文件，所以整个项目文件包含的模块非常多，导致模块的边界模糊、依赖关系不清晰、代码的质量参差不齐，混乱的堆在一起，使得整个项目非常复杂。以致每次修改代码，都非常小心，可能添加一个简单的功能，或者修改一个Bug都会带来隐藏的缺陷。
   • 技术债务：随着时间的推移、需求的变更和技术人员的更替，会逐渐形成应用程序的技术债务，并且越积越多。
   • 扩展能力受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。
   • 阻碍技术创新：对于单体应用来说，技术是在开发之前经过慎重评估后选定的，每个团队成员都必须使用相同的开发语言、持久化存储及消息系统。
      
2. 微服务
   微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。

   1. 优点

   • 易于开发和维护：一个微服务只会关注一个特定的业务功能，所以业务清晰、代码量较少。开发和维护单个微服务相对简单。
   • 单个微服务启动较快
   • 局部修改容易部署：单体应用只要有修改，就得重新部署整个应用。微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。
   • 技术栈不受限制：在微服务架构中，可以结合项目业务及团队的特点，合理的选择技术栈。
   • 按需伸缩：可根据需求，实现细粒度的扩展。

   2. 缺点

   • 运维要求高：更多的服务意味着要投入更多的运维。
   • 分布式固有的复杂性：使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的问题。
   • 接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有用到这个接口的微服务都需要进行调整。
     
     
      
3. 微服务的通讯机制
   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、异步通信：消息队列。要考虑消息可靠传输、高性能，以及编程模型的变化等；
    

4. 微服务架构基于SOA架构（SOA：面向服务化、面向业务开发）演变过来的，在传统的WebService架构中有如下问题:

   1. 依赖中心化服务发现机制
   2. 使用Soap通讯协议，通常使用XML格式来序列化通讯数据，xml格式非常喜欢重，比较占宽带传输。
   3. 服务化管理和治理设施不完善
       
5. 发展历史的总结（重要！）
   
   
   
    
6. serverless无服务

   Serverless 适合构建比较简单的应用，比如上传一张图片，对一段音频/视频进行编码或解码，对请求返回一小段数据等。

   Serverless架构主要有以下特点：

   1. 实现了细粒度的计算资源分配。
   2. 不需要预分配资源。
   3. 具备真正意义上的高度扩容和弹性。
   4. 按需使用，按需计费。

   因此以下应用将可能使用serverless架构：

   1. 静态网站的管理。
   2. 替代WordPress(Serverless Blog Project)
   3. 个人媒体服务器(less!)
   4. 物联网Iot或家庭自动框架或项目 (使用 AWS IoT)

   缺点有如下：

   1. 不适合长时间运行应用

   serverless 在请求到来的时候才运行，当应用不运行的时候会进入 "休眠状态"，下次当请求来临时，应用将会需要一个启动时间，可以叫 冷启动，如果我们的应用需要一直长期不间断的运行，处理大量的请求，那么可能就不适合使用serverless来架构了，如果这种情况下，我们需要使用像EC2这样的云服务器会是一个更好的选择。

   EC2相当于我们自己买了一辆车，在Lambda 相当于我们租了一辆车。如果我们长期租车的话，那么肯定比买车更贵，但是租车可以减少一部分车维护成本。

   2. 完全会依赖于第三方服务

   如果我们所有和应用相关的服务放在第三方服务上的话，就可能会涉及到安全性问题，因此我们可以将不重要的API或服务放在serverless上。
   当然如果我们自己有服务设施的话，那肯定使用自己的设施服务的，当我们自己使用serverless架构的时候，那么我们就已经和供应商绑定了。
   如果这个时候我们将服务迁到别的云服务商上就没有那么容易了。

   3. 缺乏调式和开发工具，排查问题困难。

   4. 无法用于高并发运用。

   为每个请求启动一个进程开销太高，流量瞬间爆发容易超时。比如淘宝的双十一支付宝高峰期，每秒处理交易笔数8万多笔，也就意味着我们的系统内每秒有8万多个进程创建又被销毁。那么这样就会造成系统开销很大。解释和第一点一样的原理。