项目学习笔记

HTTP网络协议：

• 演化过程：HTTP1.x——Google2012年提出SPDY（核心：多路复用、服务端推送）——HTTP2.0（核心：二进制解析、SPDY优化）

  详细资料参考：HTTP1.x与HTTP2.0对比

• 具体实现：Java8不支持HTTP2.0，需要借助springboot实现，并且Tomcat从8.5开始才支持HTTP/2，并且集成比较麻烦，undertow更方便。

服务间通信：

演化过程：TCP协议出现前（需要开发人员自己编程处理网络丢包等问题）——TCP协议出现（网络问题下沉，与业务代码分离）——分布式系统的发展导致业务代码新增处理负载均衡等问题的代码——spring cloud等分布式框架将处理分布式问题的代码下沉，开发者又可以专注于业务开发

总结：宏观上微服务化

微服务：

含义：区别与单体应用，将系统中的多个服务剥离开，可以单独部署每个服务
主流架构：Spring Cloud、Dubbo、Service Mesh

核心问题：服务发现 和 负载均衡
服务发现：由于每个服务可以单独部署，如何使客户端找到每个服务即为服务发现。

• 第一种：集中式管理（服务端）
  
  服务发现与负载均衡均由中间代理Gateway实现

• 第二种：客户端嵌入式
  

  代理 (包括服务发现和负载均衡逻辑)以客户库的形式嵌入在应用程序中。这种模式一般需要独立的服务注册中心组件配合，服务启动时自动注册到注册中心并定期报心跳，客户端代理则发现服务并做负载均衡。
  Netflix 开源的 Eureka(注册中心) 和 Ribbon(客户端代理)是这种模式的典型案例，国内阿里开源的 Dubbo也是采用这种模式。
  参考：微服务机构基础之ServiceMesh

• 第三种：主机独立进程
  
  以Buoyant公司linkerd产品为例，这种做法是上面两种模式的一个折中，代理既不是独立集中部署，也不嵌入在客户应用程序中，而是作为独立进程部署在每一个主机上，一个主机上的多个消费者应用可以共用这个代理，实现服务发现和负载均衡，如图所示。

  所有的SideCar就组成了一个服务网格，再通过一个统一的地方与各个SideCar交互，就能控制网格中流量的运转了，这个统一的地方就在Sevice Mesh中就被称为Control Plane（图中的service discovery），新增Control Plane的称为第二代ServiceMesh，以Istio为代表。该模式同样遵循控制与数据分离
  参考：ServiceMesh