有关Spring与SpringBoot的畅谈

1. J2EE/Jakarta EE与Spring

1.1. J2EE概述

现名为Java EE，Java 平台企业版（Java Platform Enterprise Edition）,是一种利用Java平台来简化企业解决方案的开发、部署和管理相关的复杂问题的体系结构.之前称为Java 2 Platform Enterprise Edition (J2EE)，2018年因为Java被收购的原因更名为 Jakarta EE,这里仍采用经典称呼J2EE. J2EE当年号称有十三种核心技术¹用以解决企业开发多方面的问题，如：

EJB(Enterprise Java Beans)负责核心业务逻辑，且支持分布式
JMS管理消息队列
JAXP处理XML
JTA管理事务
Java Mail发邮件...

现在它们都成为了经典(凉了...)，下面再介绍几个经典:

JSP JSP（全称JavaServer Pages）是由 Sun 公司主导创建的一种动态网页技术标准。JSP 部署于网络服务器上，可以响应客户端发送的请求，并根据请求内容动态地生成 HTML、XML 或其他格式文档的 Web 网页，然后返回给请求者。
Servlet Servlet（Server Applet），是用 Java 编写的服务器端程序。其主要功能在于交互式地浏览和修改数据，生成动态 Web 内容。狭义的 Servlet 是指 Java 语言实现的一个接口，广义的 Servlet 是指任何实现了这个 Servlet 接口的类，一般情况下，人们将 Servlet 理解为后者。
JDBC(还在用) Java 数据库连接，（Java Database Connectivity，JDBC）是 Java 语言中用来规范客户端程序如何来访问数据库的应用程序接口，提供了诸如查询和更新数据库中数据的方法。

1.2. Spring 框架

广义的 Java EE 包含各种框架，其中最重要的就是 Spring 全家桶。 Spring Frameeork Spring 诞生之初是为了改进 Java EE 开发的体验，后来逐渐成为了 Java Web ²开发的实际标准.目前Spring 是用于构建 Java 应用的一套工具的集合，包括

Spring Framework:我们通常所说的 Spring，最初是为了简化J2EE,包含 Spring AOP、Spring MVC 等一系列内容，指的是一个完整的技术栈。
Spring Boot: 一个用于快速开发的搭建工具（脚手架），"约定优于配置",开箱即用.使用它搭建出来的项目可以称为是使用了 Spring Boot 框架。
Spring Data:提供对非关系型与关系型数据库的支持，为数据访问提供熟悉且一致的基于Spring的编程模型，同时仍保留底层数据存储的特殊特性³。
Spring Cloud:协调,一个基于 Spring Boot 实现的云应用/分布式开发工具,允许服务发现和注册、负载均衡、配置中心、熔断机制等开箱即用³.

Spring Cloud Data Flow:连接,基于 Spring Boot 的工具，用于简化专注于数据处理用例的应用程序的开发和部署。目前比较常见的Spring框架组合:
SSH Structs + Spring + Hibernate
SSM Spring +SpringMVC + MyBatis

所以再解释几个名词:

Spring MVC: 基于 Spring 的 MVC 框架(Model-View-Controller),是spring 处理web层请求的现有实践模块
Hibernate 与Mybatis: ORM（Object Relational Mapping⁴）持久层开发框架,一个实现了POJO 和数据库表之间的映射,一个实现了POJO(Plain Ordinary Java Object,实体类) 与SQL之间的映射关系,都可以自动生成简单基本的DAO层方法
JPA:Java Persistence API规范,整合ORM标准,Hibernate JPA是其具体实现之一
Spring Data JPA,对JPA规范的再次抽象,包含了JPA规范和Spring项目的增加功能:分页、排序、复杂查询等

1.3. Spring思想

1.3.1. 从面向过程到面向对象

在软件业发展的初期，程序编写以算法为核心⁵。程序员会有意将数据当做问题空间的客体，程序代码则像锤子剪刀的工具加之使用来处理这些数据。这是一种站在计算机角度来抽象问题和解决问题的思维方式，也即面向过程的编程思想。之后为了适应越来越繁杂的现实世界所提出的需求，诞生了面向对象的编程思想。面向对象鼓励程序站在现实世界与业务的角度去抽象和解决问题，如此数据和处理数据的逻辑与控制也被统一到了类与对象中。

1.3.2. 管理对象--IoC(Inversion of Control)

1.3.2.1. IOC的诞生

但是人们依然发现构建大型应用时用到的类如此多以至于对类与类之间的各种依赖关系管理阻碍程序员关注实际产生价值的业务问题，于是IOC容器出现了。 IOC容器的作用就是管理类之间复杂的依赖关系,即降低类之间的耦合度，方便后期开发和维护。可以通过依赖注入 (Dependency Injection)实现解耦,因而IOC又称为Bean Factory. 没有IoC的程序中我们使用面向对象编程,对象的创建与对象间的依赖关系完全硬编码在程序中，对象的创建由程序自己控制。现在控制反转后将对象的创建转移给第三方，对象由IOC容器创建（我从哪里来），生命周期（我到哪里去）和其与其他对象的依赖关系（我与社会的关系）都由IOC容器管理。或许控制反转就是：程序员与对象交互的方式反转了。

1.3.2.2. 泛谈IOC

区别于软件开发中“以用户为出发点，以需求分析为核心”的传统模式,IOC的设计是一种“以愿景（自身利益是愿景的重要方面）为出发点，以架构为核心”的模式。从“做产品”和“做项目”的视角到“做设计”.

如何应对需求变化？ @假装刺猬的猪的答案是领域建模，并持续优化模型，适应需求的变化。@高煥堂则认为领域建模不是美好的手段。我进一步补充，应该“反过来”让自己在需求变化中处于主导地位(在你的体系下实现需求)，而不是被动地适应。--coolshell

只是这恐怕也需要这个领域内努力甩开其他的对手，然后才能成为制定标准的那一两个，掌握主动权。

1.3.3. 全局对象封装--AOP（Aspect Oriented Programming）

1.3.3.1. 传递代码块

函数式编程语言操纵代码片段就像操作数据一样容易。⁶

设计模式一个重心就是将重复的或者不变的代码与反复变化的代码分开，因此希望将代码块或方法更简洁地内联到其他代码中，或者像参数一样进行传递。Java借鉴了函数式编程的成功实践在Java8中引入了Lambda表达式用以实现这种功能：通过Lambda实现只有一个方法的接口并允许这个接口当做方法参数传入。

而面向切面编程则是在Spring的帮助下实现了在代码自己定义的切面处内联代码块。

1.3.3.2. 切面处插入模块

Spring AOP采用JDK的动态代理（反射找到有注解的方法，然后动态代理这个方法）实现AOP代理，在运行时完成AOP的aspect代码内联如原代码中。从业务的角度，AOP便是实现了在已有类和方法的前后加上事务管理,日志管理等功能，

比如现在有5个类，每个类有5个方法，如果我想要在每个方法执行完成之后打印方法名，按照没有AOP的思想就是在每个方法后面加上logger.info或者system.out.println。一共需要25行代码.这个时候AOP登场,t建立一个切面类，然后定位到这5个类的每个方法，加一个后置通知（就是方法执行完之后会执行这个通知，本质上是一个方法）。这样25行的代码简化成了一个方法加方法体的一行代码.

这样的设计遵循了面向对象的封装复用理念，即把核心业务功能（登录、CRUD 等）与周边功能（性能统计、日志、事务管理等）区分开。如下图所示：

简单说AOP将重复的功能形成组件，在需要处切入,是一种粒度更大的面向对象编程。

接下来重点介绍Spring全家桶中的SpringBoot.

2. 从WWW到SpringBoot

只有知晓了历史,才可能把握未来

话说1989年世界上第一个Web服务器和第一个浏览器在欧洲核子研究中心诞生,也标志着World Wide Web诞生...

2.1. CGI的诞生

不久后有个天才大学生Nobert写出了后世更加闻名的Ｗeb Server--NCSA httpd.但在最开始,httpd只能处理静态的html和页面,Robert于是让Server可以调用本地的程序,然后把程序的输出(本来是写到console的)直接发给浏览器.他使用的媒介称之为CGI(Common Gateway Interface)脚本编程语言.他的能力很简单,

对于每一个请求都启动一个新的进程
帮助服务器将http请求信息传递给外部程序处理

示意如下:

远古时代,虽然这些设计现在看来很多缺点,但没有CGI也就没有提供邮箱,购物,交友等服务的网站的出现. 不过CGI依赖各个平台不同的语言(C,Perletc).为了跨平台同时增强功能诞生了Servlet.

2.2. Servlet的诞生

Servlet是Java平台上第一个用于Web开发的技术。它本身就是Java类，运行于Web容器（Web Container）中,能力比较强大：

一个请求一个线程而不是进程
允许使用Session以及对对象生命周期管理
可以直接调用JDK的API(比如直接构建业务对象，使用JDBC)以及生态提供的服务（比如JVM的GC）

示意如下：因为它一个类就可以实现众多功能，因而也被称作“Magic Servlet”,但是另一面便是违背了“高内聚，低耦合”的开发原则（血泪的教训...），各种逻辑混杂于一处：

流程控制逻辑
视图显示逻辑
业务逻辑
数据访问逻辑

尤其是视图显示是使用out.println("<html>")这种语句拼接而成,继承自CGI的在代码中输出html的方式广受诟病,是当时急需解耦的问题。

2.3. JSP的诞生

人们想到了使用模板化（templating）的方法将View从Servlet中以独立的单元抽离出来，于是提出来JSP页面技术。虽然还是将Java代码和HTML写在一起，但是原本需要out.println（）的语句被集合在一起做成了模板,Java语句则放在了html下方的Scriptlet中.然而这依然允许任何应用程序逻辑都融入Scriptlet中,眼看着又要诞生另一个"Magic JSP".

2.4. Servlet与JSP的联盟

2.4.1. JSP Model2的诞生

JSP功能的强大却演化成了一种不良诱惑,程序员终于意识到技术不应该滥用.

当你只拿起锤子,你总要发现周围的钉子.

不管Servlet与JSP本身能做到什么,

Servelt只负责请求处理逻辑的控制以及与业务层的交互
JSP只负责视图的渲染逻辑
再引入封装业务层逻辑的JavaBean

这样的架构被称之为JSP Model2,其示意图如下:

这便是MVC的雏形.但是仍有一个很大的区别,可以看到早期视图与模型之间的数据同步工作是模型push数据到视图,而MVC模式中,Contrller是主导地位,它从Model中pull数据然后返回给View.

2.4.2. 分离具体的Web请求逻辑

在JSP Model2实践中,人们对Servelt有两种选择:

一个Servlet对应一个Web请求
单一Servlet作为集中控制器

为了集中管理Web请求的处理流程与维护web.xml的简单,第二种逐渐成为主流.但是因为控制逻辑是硬编码在Servlet中的,一旦要调整url映射的处理,就得修改Servlet控制器的代码并重新编译,于是继续解耦,对原先耦合度高的控制器逻辑逐步分离.

Web开发框架主要分为两种:

请求驱动
事件(GUI)驱动

对于请求驱动的JSP Model2,继续限制Servlet的功能,将其瘦身为Front Controller,并参照外部可配置的流程规则,将Web请求转发给Sub/Page Controller进行处理.在曾经使用的Structs中,ActionServlet便是Front Controllert,Action便是Page Controller,同时结合structs-donfig.xml对url与Action之间进行映射.

2.4.3. 解耦视图类型的选择和渲染(Render)与具体控制器

传统的JSP视图文件渲染逻辑如下:

request.setAttribute("infoList",infoList);
forward(request,response,"view.jsp");

可以看到JSP需要依赖request对象来传递模型数据,依赖RequestDispatcher来输出最终的视图.但是模板技术远不止JSP一家,还有*.vm,*xls等等.所以仍然需要将处理后的模型数据与具体的View实现技术(如*.jsp或者之后的.html)解耦. Spring MVC引入servlet.view接口来统一抽象视图的生成策略,使得DispatcherServlet只需要根据Controller处理完毕后通过ModelAndView返回的逻辑视图名称查找到具体的view实现即可.同时与url与Page Controller之间的映射类似,再引入了servlet.ViewResolver来处理逻辑视图名与具体View实例之间的映射关系. 注意这里的View实例可以包括Excel与PDF形式的文档视图甚至自定义的.

2.5. Spring MVC的诞生

Spring MVC是Spring的一个web框架。通过Dispatcher Servlet, ModelAndView 和 ViewResolver，解决网站应用程序或者服务开发——URL路由、Session、模板引擎、静态Web资源集成等方面的问题。

2.5.1. Spring MVC的低耦合性

Front Controller-->servlet.DispatcherServlet
- HandlerMapping处理Web请求与Handler之间的映射关系
Page Controller-->Handler-->mvc.Controller实例
JavaBean-->Model
JSP* -->View
- ViewResolver来处理逻辑视图名与具体View实例之间的映射关系

2.5.2. 基于注解的Spring MVC

以Controller为例,基于Annotation的Controller和传统的Controller没有什么区别,都是普通的POJO.Java 通过元注解⁷定义在被注解的类结构上得到注解，然后这个注解再被使用，借助Java反射实现被注解的类功能。即Java注解的形式和功能是分离的，本质是语法糖,这不同于 Python 的装饰器⁸会直接传递功能类，两者好比引用传递和值拷贝的关系。对于基于注解的Controller,它至少需要解决两个问题:

Spring MVC框架类(DispatcherServlet)怎么知道当前Web请求应该由哪个基于注解的Controller处理?
Spring MVC框架类怎么知道基于注解的Controller的哪个方法来处理具体的Web请求?

解决方法简单说:

注解中附加了有用的元数据信息与基础类
基于约定或配置扫描有关注解类并纳入IoC容器进行管理
- 比如将@Controller 注解的类作为 URL 路由注册到 DispatcherServlet中，并在创建 Tomcat Server 时传入请求处理器
AOP动态代理

常用注解介绍

@Bean⁹

@EnableAutoConfiguration开启自动配置功能
@AutoConfigurationPackage将主配置类(@SpringBootApplication)的所在包以及下面所有子包里面的所有组件扫描到Spring容器
http方法映射
- @RequestMapping提供路由信息，负责URL到Controller中的具体函数的映射。如果没有指定请求方式，将接收Get、Post、Head、Options等所有的请求方式。
  - @GetMapping==@RequestMapping(method = RequestMethod.GET)的缩写。该注解将HTTP Get 映射到特定的处理方法上。
  - - Get示例:
  https://yihui.wang/ares/goods/detail/?goods_id=55
  - 同理PostMapping==@RequestMapping(method = RequestMethod.POST)
  - - Post示例:
  http://localhost:8080/wx/auth/profile?username=user123&password= user123
@Controller用于定义控制器类，在spring项目中由控制器负责将用户发来的URL请求转发到对应的服务接口（service层），
- 配合注解@RequestMapping,返回一个视图(前后端不分离)
- 配合@ResponseBody当返回值是String，返回的字符串将不再通过ViewResolver查找视图(即.jsp或.html文件)，会被直接以 JSON 或XML形式数据展示在浏览器里
@AutoWired自动导入依赖的组装好属性、方法的Bean,可以对类成员变量、方法及构造函数进行标注，把配置好的Bean拿来用.比如:Service 类注入到 Controller 类中。

@Service
public class UserService {
  ......
}

@RestController
@RequestMapping("/users")
public class UserController {
   @Autowired
   private UserService userService;
   ......
}

非空校验注解

@NotEmpty用在集合类上面,不能为null，并且长度必须大于0
@NotBlank用在String上面,只能作用在String上，不能为null，而且调用trim()后，长度必须大于0
@NotNull 用在基本类型上,不能为null，但可以为空字符串

后来人们越来越喜欢用注解,并且发现还有大量重复的代码可以打包变成依赖,或者干脆基于Convention Over Configuration(约定优于配置)的方式省略这些代码,于是诞生了Spring Boot.

2.5.3. 新一代的模板引擎thymeleaf

类似于Angular的值引用,将大量的data可以通过{user}这种方式填充在对应的模板里,最后生成html时由自己再转化

2.6. Spring Boot 的诞生

2.6.1. 让开发更简单!

2.6.1.1. 简化依赖导入

导入SpringBoot相关依赖

<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>

实际上点进去starter-web:

<dependencies>
    <dependency>
    ....
      <artifactId>spring-boot-starter</artifactId>
      
      <artifactId>spring-boot-starter-json</artifactId>

      <artifactId>spring-boot-starter-tomcat</artifactId>

      <artifactId>spring-web</artifactId>

      <artifactId>spring-webmvc</artifactId>
    ....
    </dependency>
</dependencies>

可以看到starter-web这个依赖中已经包含了Spring Web需要导入的多个依赖.此外这每个依赖又封装了许多不同功能的依赖.这是Spring将功能场景抽取成各个Starter的设计,需要开发什么功能,导入这个功能场景对应的依赖包就好.

2.6.1.2. 简化配置

如@Service=@Configuration+@Bean:

@Configuration
public class JavaConfig {
    @Bean
    public TestService getTestService() {
        return new TestService();
    }
}

@Configuration 表示该类是个配置类， @Bean 表示该方法返回一个 Bean。这样就把TestService 作为 Bean 让 Spring 去管理了，在其他地方，我们如果需要使用该 Bean，和原来一样，直接使用@Resource 注解注入进来即可使用:

@Resource
private TestService testService;

不过对于底层的大量封装也难免带来开发人员对于底层原理的忽视.

2.6.1.3. 简化部署

传统打包成传统的WAR文件，并部署到一个外部的应用服务器(如Tomcat的/webapp下) 现在

maven插件打成jar包,或者Webjar类似于前端里的Webpack 创建一个独立的（standalone）应用程序,由古老的main()方法驱动
java -jar运行采用Spring提供的嵌入（embeded）的Tomcat Servlet容器作为HTTP运行时环境，不需要部署一个外部的运行时环境实例。

2.6.1.4. 简化监控

2.6.2. 还能再解耦吗?

其实SpringBoot采用的是面向过程的分层管理(注意分层只是管理手段)：

2.6.2.1. DAO层: 持久层，与数据库交互

在配置文件中进行配置数据源和数据库连接的参数 -->DAO层-->创建Dao接口(可以在这里引入sql或xml中配置映射)-->在模块中调用Dao的接口进行数据业务的处理

2.6.2.2. Entity层: 实体层，数据库在项目中的类

定义与数据库中字段对应的实体类，并提供get/set/tostring方法等。

2.6.2.3. DTO层、Model层: 全项目最惨工具人

与Entity层功能类似，但是其中模型类不与数据库中字段对应，处于数据转化的中间地位(某种程度上就是工具人)。

2.6.2.4. Service层:业务层设计分类的业务逻辑

在Service层封装一些业务逻辑帮助业务逻辑独立与复用，所以事实上小型项目中Service可能是多余的，完全可以并入Controller中

2.6.2.5. Controllor层:控制层控制调用哪个业务逻辑

Controller负责具体的业务模块流程的控制；Service层负责业务模块的逻辑应用设计

2.6.2.6. View层

随着前后端分离的大趋势,View层此前主要响应Controller层对jsp页面的请求,现在则归属前端的范围.得到后端的数据(如json)之后处理,渲染,呈现数据.

2.6.2.7. 简单总结

在C/S架构下，Controller层调用Service层的方法，Service层调用Dao层的方法，其中调用的参数是使用Entity层进行传递的，中间可能用到工具类可以再做个util层以及中间件做个middle层，还有工具人用上DTO层。最后Controller层响应Client的请求返回结果给View层.

2.7. 前后端分离--将数据与视图显示继续解耦

生活中类似于基于模板的生成方式很是平常,比如

利用模子来制作各种形状的蛋糕/瓶子
使用方印染不同的印泥后盖章

但是我们也注意到模具与实例之间是可以完全分离的,实例的一部分不需要放在模具中。所以之前的模板技术还可以继续解耦.于是诞生了前后端分离,开始流行返回json而不是逻辑视图名。另一方面，从管理学的角度，这也符合团队成员各司其职的原则。

2.8. SpringBoot优化

2.8.1. SpringBoot刀刃的另一面

Spring本质上就一个IOC容器，SpringBoot相对Spring像一个全家桶，为其加入了DI/AOP/注解封装等各种功能支持，也因此显得臃肿。相对Spring来说¹⁰，

一堆配置无非就是从xml变成annotation或是*config.java
- Spring Boot框架尽管通过组合注解方式实现了诸多Spring注解的组合，但是注解依旧会被大量重复地用到各个类或者方法中
tomcat、jetty等只是被内置了简化了部署，但是要想容器调优除了依旧要深入tomcat等具体的容器知识，还必须知道在SpringBoot的体系下tomcat怎么配置

此外(这个说到底是自己的问题)：

开箱即用也带来了相当的黑盒恐惧感，比如AutoConfiguration配置了哪些东西?我自己要覆盖配置怎么办？

2.8.2. 与SpringBoot相关的痛点

IO耗时过长 -> 增加Cache(如Reids),以避免频繁调用一些不变的数据
业务模式比较复杂 -> 对代码做非空校验，引入注解/配置等¹¹
并发量比较高 -> 后端异步返回的数据量很大+时间很长,故调大异步返回的最大时间以及对返回信息做压缩,以增加网络传输效率
Controller层无法完全满足跳转的需求等

2.9. 泛谈架构分层

2.9.1. SpringBoot 中的分层

SpringBoot通常分为

Dao
Entity/Model
Controller
Service

分层设计基于单一职责原则（SRP-Single responsibility principle）让每个对象各司其职、各尽其能，达到软件架构“高内聚、低耦合”的要求。

2.9.2. 其他领域的分层

2.9.2.1. 通信领域

TCP/IP的

应用层
传输层
网络层
链路层
物理层

OSI：

应用层
表示层
会话层
传输层
网络层
链路层
物理层

网络层屏蔽底层细节而承接上层接口，达到“everything over IP”以及“IP over everthing”的功能设计，是体现“高内聚，低耦合”的非常好的案例。

everything what is over IP : 不管哪种数据形式，图像，声音，文件...通过确定的传输层协议TCP/UDP/FTP...就可以通过IP包送到目的地
everthing what Ip is over:
- 屏蔽不同的通信子网：以太网,ATM,卫星网，4g网...
- 硬件接口为此向IP靠拢：硬件接口在操作系统里抽象成一个接口，IP可以从这个接口里收发IP报文

2.9.2.2. 互联网架构领域

把底层的支持与实际产生价值的业务分离开，但是底层是技术的真正所在。很多程序员入门时就从业务开发开始了。

2.9.2.3. 软件开发分层

参考《阿里巴巴开发手册》：

2.9.3. 与程序的关系

这背后是基于对

Program = Logic+Control+Data Structure

中项目各组成元素的分离. Data Strcuture是对现实数据及对象的抽象或者说建模,是接下来要使用的实体; Logic实现对已定义的实体的处理,关注"What"; 最后Control部分关注业务逻辑,操控怎样地组合各种封装好的Logic,关注"How" 三者的分离是写好程序的关键,Logic与Control是解耦的关键:

Dao层实现与数据库的接口并与Entity层中的实体一一映射
Service层实现Dao层中的接口并设计业务逻辑,代表的是Logic的部分
Controller层则响应客户端的请求,控制业务逻辑的调用,代表Control的部分

面向对象的本质是面向数据库开发

3. 从一个SpringBoot到微服务

3.1. 单体架构的无奈

在同一个服务器上部署同一个系统，往往是比较容易部署于测试的。但是随着需求的不断膨胀，单体应用欲图通过使用统一的技术平台解决所有的问题是不现实的（Node.js想统一前后端也受限于此）。

3.2. SOA的诞生

3.2.1. SOA(Service Oriented Ambiguity)

围绕着业务就是围绕着价值，于是面向服务架构的SOA概念随之诞生。SOA通过将彼此链接的、可重复的服务整合降低成本；又为了提高系统负载能力，实现高内聚低耦合，

将一个大的系统划分为多个业务模块，并分别部署在不同的服务器上；
数据库也采用分布式数据库，如Redis/ES;
服务器通过LVS/Ngnis实现负载均衡；
引入资源调度与治理中心

同时不同服务之间的交互通过RPC实现。

3.2.2. RPC的沿革

早期实现跨物理机的远程访问另一个进程唯一的方式就是RPC（Remote Procedure Call）（Socket 属于私有协议数据通信）.在SOA提出后，RPC通过消息队列(如RocketMQ)解决被动调用问题，通过发布与订阅实现消息异步处理。如今RPC既作为一种比tcp或http等更高层的服务请求协议存在，也作为内部服务管理框架在发展。

http作为一种最常用的交互方式，在内部系统服务调用很复杂的情况下，包括效率和安全性在内，需要一个内部服务的管理系统--即RPC。本地调用的过程至少需要涉及

确定的类或参数
类或函数的参数
类或函数的返回值

与任何一种协议的报文设计类似，同样需要将这些参数进行合适的编码设计。作为RPC协议中服务A调用服务B的过程双方，

对于服务A：

序列化
协议编码
网络传输

对于服务B：

反序列化
协议解码
网络传输

而在更大意义上，作为内部服务框架的RPC，涉及

服务注册
服务治理
服务发现
熔断机制
负载均衡等

3.2.3. RPC的实现

基于TCP实现：底层自定制字段，减少网络开销
基于HTTP实现：
- 可以使用JSON或XML格式的请求或响应数据
- HTTP无状态便于联系同时降低复用
- 先得建立TCP连接，字节数占用多

3.3. Spring Cloud的诞生

当系统复杂度再跳，进一步将系统拆分成许多小应用（也是服务，但是有更强的独立部署能力）。微服务将业务逻辑分散到不同的物理机，不同的进程下.¹²单应用的故障与负载不会影响到其他应用。最吸引人的在于每个微服务可以使用自己适宜的技术栈 。Java领域以Spring Cloud与Dubbo为代表框架实现微服务。

Spring Cloud=服务发现+负载均衡+限流熔断降级+网关+Spring Boot+分库分表+读写分离

每一个功能元素放在一个独立的服务中---就像装配式建筑一样,不过要有多微?-->参考官方文档
单元和单元之间的通信通过http方式(无协议状态)进行Rest方式的连接；不再使用RPC

3.4. 复杂化后的Service Mesh

一言以蔽之：Service Mesh是微服务时代的TCP协议。¹³

3.5. PaaS的诞生

各自服务的单打独斗依然会带来重复劳动，比如各自部署自己的ES，开发某一个小服务。前者是资源需要整合以便弹性调用；后者或许可以通过共享库解决但是在多语言版本时也不可行。于是严谨思考业务场景各自的边界从而严格限制每个微服务的边界，并整合成大中台系统，即我们常说的PaaS层（平台即服务）。

3.6. Serverless的窥视

3.6.1. 只管付钱的野心

基于云计算，开发者能做到真正只关注业务。云端可以自动分配存储和计算资源，并提供标准REST API的接口。

3.6.2. 资源背后的故事

在最开始单机上的多用户就有了分割计算机资源的想法，并诞生了虚拟化技术，将底层的计算机资源抽象成多组相互隔离的计算平台。下面图片来自码农翻身公众号： LXC1

纯软件实现的虚拟化有两类，一类是在硬件上运行操作系统，在操作系统上安装虚拟化软件，创建各种虚拟机，这是2型虚拟化，由于中间隔着一个宿主操作系统，2型虚拟化的效率并不高。还有一类是1型虚拟化，在硬件上安装Hypervisor、在其上运行各种虚拟机，这种方式更加彻底，更加可靠。和虚拟化相对的是更轻量级的容器，这种技术将操作系统内核虚拟化，允许用户空间的进程隔离起来，形成一个相对独立的运行环境¹⁴。现在云端的资源分配只是历史的进程之一。

3.6.3. 列举一些资源细节

Tomcat 默认配置的最大请求数是 150，也就是说同时支持 150 个并发(传统BIO模式下)
Windows 每个进程中的线程数不允许超过 2000
Linux 每个进程中的线程数不允许超过 1000
Java 中每开启一个线程需要耗用 1MB 的 JVM 内存空间用于作为线程栈之用

4. About Me

javaEE的13种核心技术 ↩
由Java语言主要实现的浏览器可以访问的程序内容 ↩
Spring Data JPA是什么（Spring家族） ↩ ↩²
ORM采用元数据（可以是xml格式）来描述对象与关系映射的细节。元数据描述数据，是对数据及信息资源的描述性信息。 ↩
深入理解Java虚拟机，周志明，2020年版 ↩
JAVA编程思想 ↩
即定义注解的注解，与元数据类似，如@Target({ElementType.TYPE})注解适用类型与@Retention(RetentionPolicy.RUNTIME)注解生命周期等 ↩
DisSpringBoot ↩
Spring中Bean及@Bean的理解 ↩
SpringBoot vs Spring ↩
在MyBaitis的xml里,select语句where条件有innull即这个值有就增加一个where条件,借此对任何一个where增加一个不带isnull的查询条件,以免改语句当传入参数都是null时,做全表扫描 ↩
微服务发展沿革 ↩
什么是Service Mesh ↩
我终于实现了前辈的梦想！ ↩