2020.4.19
之前本来想写博客一步一步的搭建直播。。但是实在是太累。。就直接写好提供下载了。。
要说的都写在项目中代码注释里。这样也比写博客弄截图来的方便快捷~~~~文件在审核。
首先统一一下开发环境~这里ORM使用的是Mybatis（其实可以每个服务不同选择）
运行环境
JDK11
MYSQL8
SpringCloud Hoxton.SR3
SpringBoot 2.2.6
Lombok插件别忘了装一下
DEMO结构图：
说明：
1.本项目为一个MAVEN总工程下以模块的方式创建服务，这也是多数企业为服务项目的创建方式。优点：整个项目在一个maven工程中，down一次代码可得整个项目...缺点：恕我直言，这种项目一般还是需要开发者参与各模块的业务开发，从项目构建到工作范围来讲不能彻底解耦（也就是说业务微服务了，人员基本不会一个服务一个人搞~）。每一个服务都通过API去暴露feign接口的话会导致很多没用的依赖。总体来说:"架构微服务,结构ALL IN ONE"。
2.结构说明 ：
这里举例默认是Consumer-80服务需要调用Provider-8001服务，API为公共部分，被各个服务共同依赖，这里存放8001暴露出的接口。在80中调用。
7001为注册中心。可以复制几份。做高可用集群
3.启动顺序：先启动注册中心7001 然后启动8001 再启动80，测试调用80中的接口
4.特别说明 这里默认是80消费8001的业务。有些时候并不是这种单向消费关系（如8001需要80提供服务支持）。这里只是基础框架
5.另一种实现...
单说项目结构，另一种更理想的方式是每个微服务仅仅只是一个SpringBoot单体项目。独立Maven工程构建（就像是单体服务），当然注册中心也独立出来。其中单个服务项目如图
此服务可视为传统的单体应用，仅对各业务层（纵向）分模块构建：
api - 本服务对外（其他服务）暴露的FeignAPI（这边相当于把上面那个结构的API模块按提供者拆分到各个子项目，可以需要就继承）这边把这个模块打包，在需要使用的服务中以Maven依赖的方式引入。
entity - 本服务实体 就是放 bean
repository - 本服务数据访问 即 Dao层
service - 就是单体的service
web - 就是 controller层。本服务对前端暴露的API
（这种命名法跟业务流向一致，具有顺序性 更可读，从下到上依赖）
这种直微服务项目组建形式可以更好的解耦各个微服务业务。
相必还会更好上手：一个新员工接手代码。不用了解整个应用的业务逻辑，只需关注当前服务的特定业务。对于其他服务的调用来说一切都是面向接口编程，自顾自（知道自己需要什么、找谁要。知道自己做什么，按须提供接口）即可
另外，API中（包括上面的那种代码结构）我并不推荐直接暴露实体出去。一切接口应该封装成仅带有所需字段的对象提供出去，类似Controller返回给前端的VO，这里可以定义AO给服务间数据交互。
还有一点：既然按照这种划分，每个服务被独立成一个项目。则框架的选择方面将会更加灵活。尤其ORM层体现尤为明显，你可以使用Mybatis来完成你的模块。他可以使用JPA来完成它的模块。甚至！还可以使用其他语言编写~ 这样好处就是可以看个人喜好快速开发。弊端。。。建议不这么做就是了，其实上面的那种结构也可以这么骚。但是同一个公司还是统一技术站比较好。。。除非是分模块外包~随你怎么搞。
数据库层面不用说，每个服务都建议使用独立的数据库，需要别的数据从业务层开API调用实现。
