＜2021SC@SDUSC＞博客（4）山东大学软件工程应用与实践JPress代码分析（三）

2021SC@SDUSC

前言

在前两篇文章中，我对 JPress 项目和 JBoot 框架的基础 JFinal 框架的使用方法做了简单的分析与介绍，目的是为后续分析 JPress 项目打基础。三个项目的结构图如下，接下来我将对 JBoot 框架做简要分析。

JBoot 框架简介

官网所给的介绍是这样的：

JBoot 是一个基于 JFinal、JFinal-Undertow、Dubbo、Seata、Sentinel、ShardingSphere、Nacos 等开发的微服务框架， 帮助开发者降低微服务开发门槛。同时完美支持在 IntelliJ IDEA、Eclipse 下多 Maven 模块，对 Java 代码、HTML、CSS、JavaScript 等资源文件进行热加载。

通过对 JBoot 框架所提供的服务进行递归学习之后得出，JBoot 框架使用大量的中间件框架，主要用于高并发、分布式场景下的互联网类应用开发，方便开发者进行微服务开发。由于我并未对该类场景的项目有过相应的开发经验，所以我首先学习了微服务相关的基本概念，并简单学习了 JBoot 框架的使用方法。

微服务

要理解微服务，首先需要理解什么是单体应用。

在没有提出微服务的年代，一个软件应用往往会将应用所有功能都开发和打包在一起，于是那个时候的 B/S 应用架构是这样的：

但在互联网应用的场景下，用户访问量远远超过一台服务器所能支撑的能力，这时候就可以加服务器、加负载均衡，于是就变成这样了：

再往后发现把静态文件独立出来，使用 CDN 等技术手段进行加速，可以提升应用的整体响应速度，架构就变成了这样：

这个架构比较类似于我现在做开发时的架构，但依然属于单体应用架构，存在单体应用的根本缺点：

• 回归测试周期长，修复一个小小 BUG 可能都需要对所有关键业务进行回归测试。

• 应用容错性差，某个小小功能的程序错误可能导致整个系统宕机；

• 伸缩困难，单体应用扩展性能时只能整个应用进行扩展，造成计算资源浪费。

• 开发协作困难，一个大型应用系统，可能几十个甚至上百个开发人员，大家都在维护一套代码的话，代码 merge 复杂度急剧增加。

显然这样的架构无法满足互联网产品的技术需求，于是微服务架构就应运而生了。

微服务的要点有两点，第一点是单一职责，即一个微服务只解决一个业务问题；第二点是面向服务，即将自己的业务封装并对外提供服务。由此，我们大致可以知道微服务的基本单元就是服务。

在理解了微服务后，就会遇到微服务治理问题。在一个业务中，会有多个微服务，于是首先遇到的问题就是一个微服务如何发现其它微服务。最简单的方式就是每个微服务里面配置其他微服务的地址，但这显然大大提高了系统的耦合度。所以微服务中第一个重要组件是服务注册中心，所有服务都注册到服务注册中心，同时也可以从服务注册中心获取当前可用的服务清单。

解决服务发现问题之后，会出现第二个问题，即服务配置的管理问题。当服务数量超过一定程度时，如果每个服务里都有一个服务配置文件，同样耦合度会增大，这就需要用到第二个重要组件配置中心。

以上时应用内部的服务治理，但当客户端或外部应用调用服务时，服务1可能有多个节点，而服务1、服务2、服务3的服务地址都不同，这样直接调用起来就非常麻烦。这时，就需要使用到服务网关提供统一的服务入口，最终形成典型的微服务架构。

当然，微服务治理还包括大量的其他内容，如熔断、限流、负载均衡、分布式事务、服务调用链跟踪等，后续如果有机会会逐步探讨到。

其他服务

JBoot 框架包括大量的与微服务有关的内容，因为不熟悉的关系，这里只做简单的介绍。

缓存

微服务的根本目的是降低系统间的耦合度，提高服务响应速度和容错性，因此缓存的合理设计必不可少。JBoot 框架内置了丰富的框架支持，如 Ehcache、Redis、Ehredis、Caffeine、Caredis、J2Cache。我们可以通过 JBoot 框架提供的工具类 CacheUtil 来使用缓存。

//添加内容到缓存
CacheUtil.put("cacheName","key","value")

//添加内容到缓存，并设置该缓存的有效期为 10 秒钟
CacheUtil.put("cacheName","key","value",10) 

//获取缓存内容
String value = CacheUtil.get("cacheName","key");

//删除缓存
CacheUtl.remove("cacheName","key")

//重新设置某个缓存的有效期
CacheUtil.setTtl("cacheName","key")

RPC

RPC 指的是远程过程调用，即一个应用部署在 A 服务器上，想要调用 B 服务器上应用提供的服务，由于不在同一个内存空间中，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。

一般情况下，RPC 调用需要以下几个步骤：

1. 定义接口

   public interface BlogService {
       public String findById();
       public List<String> findAll();
   }
   

2. 编写实现类

   @RPCBean
   public class BlogServiceProvider implements BlogService {
   
       @Override
       public String findById() {
           return "id from provider";
       }
   
       @Override
       public List<String> findAll() {
           return Lists.newArrayList("item1","item2");
       }
   }
   

3. 启动 Server 暴露服务

4. 启动客户端，通过 RPC 调用 Server 提供的服务

后续两个内容涉及到 Dubbo 或 Motan，不在能力范围内，留到后续对 JPress 源码分析时再介绍。

其他

JBoot 框架还包括 MQ 消息队列、GateWay 网关、任务调度、限流、监控、单元测试、热加载等内容，不论代码还是文档我基本都看得不是很懂，分析就留作给后面挖坑了。

总结

简单地看了一下 JBoot 框架的文档和代码，因为没有对应的开发经验，所以基本上看不懂他做的是个啥东西，只能自顶而下看看框架的整体设计，所以这里不做过多的分析，后面将进入 JPress 环节。