微服务思想与开发规范

1. 概述

   微服务是一种开发结构，通过将各个业务场景的功能按模块拆分，一方面是避免不同业务的代码相互糅合，造成业务处理目标不明晰，功能耦合的问题；另一方面是方便代码的复用，当多个客户的各种需求存在相似处，例如都有下单支付、日志控制等功能 可以直接复用 通用的 业务模块代码 ，只需要简单个性化修改即可，提高开发效率。

2. 规范

项目中，可分为：
  ①版本控制模块dependencies
  ②通用功能模块framework
  ③业务功能模块bussiness
  ④入口服务模块server

3. 模块介绍

①版本控制模块

  是为方便做整个工程中，功能模块引入的组件库依赖的版本管理，可以理解为常规开发中，在Project的pom文件做的版本控制，与这种方式的区别是：
   在项目升级为分布式系统时，不同业务模块需要的组件依赖库的版本号 存在不同，就存在版本冲突的问题：模块1的依赖需要在Project的pom或自己的模块中一个个编辑修改，模块2的依赖也需要重新修改。
  使用版本控制模块就能分成多个不同的版本的依赖库，可以直接引入相应需要的依赖库，就能方便地解决问题，不会造成版本代码紊乱，也能提高复用率。

②通用功能模块

   是将工程中大层面上通用依赖及其功能和配置，整合成一个模块，通过引入，就可以直接获得关于：mybatis、redis、MINIO等功能的依赖的配置。
   一是方便引用，二是减少代码的重复和冗余。

③业务功能模块

  是针对任意业务场景下，按功能区分的代码模块，内部分为2个大目录：
1、api（用于模块之间的远程调用）
2、biz（用于编写业务代码，由客户端和管理员端进行HTTP调用。
   在主要的业务功能编写中，是在biz模块进行的。
   api模块的目的是暴露接口，当需要调用到其他模块的功能时，可以通过接口直接调用，而不用涉及到直接调用对方的service业务接口，避免了暴露所有的业务接口，可作为远程调用RPC。

总结：

   要业务模块biz之间调用功能，在调用者[biz]的pom中引入被调用者[api]的依赖，再在要使用的位置，直接引入该暴露的功能接口
[interface]
  要B或C端发送Restful请求调用biz模块的功能，就直接在controler中写接口。

④入口模块

   是整个工程的入口，通过引入需要的业务功能模块，就能开启和拥有相应的功能，然而必须选择其中2个场景，一是系统功能system，二是通用设置功能框架infra，这两个功能是后台管理系统的大骨架，其他的业务功能模块是侧边菜单栏中的任意一个业务功能，可以按需添加。
   整个工程只有这个模块运行有@SpringBootApplication/ServerApplication这个入口运行类，其余模块按照规范就不添加了，这是为了减少项目启动的冗杂，清晰地知道测试和开发运行入口，提高效率。
   并且这个模块中的配置文件是用于配置整个工程的服务器配置信息的，诸如：mysql-jdbc连接配置等等信息。
  还有在pom.xml中能指定打包的信息。