一、单体应用

1、定义：一个归档包（例如war包）包含所有功能的应用程序，通常为单体应用。而架构单体的方法论，就是单体应用架构。
在这里插入图片描述
2、优缺点：

（1）优：

架构简单
开发、测试、部署方便

（2）缺：

复杂性高：项目大，模块边界模糊、代码质量参差不齐、人员质量参差不齐，随着功能不断变化，项目越做越混乱，最后导致项目越来越复杂，加简单功能，修改bug都会带来许多问题
部署慢、部署频率低：全量部署，每次影响范围大，上线风险高
扩展能力受限
阻碍技术创新：换框架难，尝试新技术风险高

二、微服务

1、定义：把复杂系统拆分成若干个小型应用，小型应用通过协作共同构建一个系统，每个小型应用就是所谓的微服务。

2、特性：
（1）每个微服务可以运行在自己的进程里（意味着每个微服务都有自己的tomcat）
（2）一系列独立运行的微服务共同构建整个系统
（3）每个微服务为独立的业务开发，一个微服务只关注某个特定的功能，例如订单管理、用户管理等
（4）可以使用不同的语言和数据存储技术（契合项目情况和团队实力）
（5）微服务之间通过轻量的通信机制进行通信（通信协议轻量、允许跨平台），例如REST API 进行调用
（6）全自动的部署机制：微服务的基石，微服务并不是一个开发框架，是一个完整的架构方法论，此方法论前提就是能自动化东西尽量自动化，如构建、部署、测试

在这里插入图片描述
3、优缺点：
（1）优：

单个服务更易于开发、维护
单个微服务启动较快
局部修改部署容易
技术栈不受限
按需伸缩：若某个服务比较耗CPU，只需将此服务迁移到CPU性能强的服务器

（2）缺：

运维要求高（需求全自动部署机制）
分布式固有的复杂性（微服务本职就是分布式应用，如网络延迟、分布式事务）
重复劳动：如A服务有stringUtil，B服务也需要stringUtil,且两个服务采用不同语言，就需要重复劳动，就开发两遍

4、应用场景：
（1）适合场景：大型、复杂的项目（能用单体架构搞定，无需使用微服务）；有快速迭代需求；访问压力大（去中心化，每个服务都有各自数据库，吞吐率高）
（2）不适合场景：业务稳定；迭代周期长

三微服务拆分

1、业界流行的方法论：领域驱动设计（domain driver design，ddd）、面向对象（状态 by name、行为 by verb 思考问题）
2、个人心得：职责划分、通用性划分（用户中心、消息中心）
3、合理粒度：良好满足业务；幸福感，团队没人认为微服务太大、难维护、部署高效；增量迭代，微服务相对独立；持续进化，更换技术选型方便
4、小程序拆分（实际情况更适合使用单体应用，在此仅为演示使用）
（1）使用面向对象，将小程序拆分为用户中心、内容中心；用户中心是按照通用性划分；内容中心是根据职责划分，关心与内容相关的业务
在这里插入图片描述

四数据库设计

1、数据建模
在这里插入图片描述
PS：建模工具mysql workbench，支持将模型导出sql语句，进行快速创建

2、把表建好

五小程序创建

请移步到GitHub到老师的开源项目

六创建项目

1、技术选型

（1）spring boot（快速开发）
（2）spring MVC（MVC框架爱）
（3）mybatis （持久层框架，操作数据库）+ 通用mapper
（4）spring cloud Alibaba（分布式）

2、工程结构规划图

在这里插入图片描述

3、用户中心、内容中心 SpringBoot应用快速搭建

（1）使用spring initializr快速创建SpringBoot应用
（2）加依赖：

通用mapper，4.0后，无需添加mappers参数（之前此参数十分重要），需要加上@MapperScan或者在所有接口增加@Mapper

（3）加配置
在这里插入图片描述
（4）专用代码生成器配置并使用（还有通用代码生成器，上手难，暂不使用，感兴趣自行研究，GitHub mapper代码生成器）

maven插件配置

org.mybatis.generator
mybatis-generator-maven-plugin
1.3.6

${ basedir}/src/main/resources/generator/generatorConfig.xml

true
true

mysql
mysql-connector-java
8.0.16

tk.mybatis
mapper
4.1.5
generatorConfig.xml文件配置
① 修改resource路径，并在同层级文件夹创建config.properties文件，并添加配置
② 实体类、xml、dao接口文件自动生成配置，并在config.properties加入需要生成的模块名及表名

③ 执行生成文件，刷新，并点击生成工具

PS：实体类字段异常，需更改config.properties配置

（5）lombok使用，简化代码编写，提升开发效率

<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <version>1.18.8</version>
    <scope>provided</scope>
</dependency>

@Builder 建造者模式
代码生成器使用lombok，在generatorConfi.xml中配置

七 IDEA红色警告解决

老师完成的笔记总结

1、@Autowired 红色警告：默认情况要求依赖对象必须存在。而idea认为这个对象实例/代理是null，所以给了友好提示。解决方法：

设置requestd = false，注解不再去校验userMapper是否存在，因此不产生警告
用@Resource替代@Autowired 两者区别：
① @Resource是Java自己的注解，@Resource有两个属性是比较重要的，分是name和type；Spring将@Resource注解的name属性解析为bean的名字，而type属性则解析为bean的类型。所以如果使用name属性，则使用byName的自动注入策略，而使用type属性时则使用byType自动注入策略。如果既不指定name也不指定type属性，这时将通过反射机制使用byName自动注入策略。
② @Autowired是spring的注解，是spring2.5版本引入的，Autowired只根据type进行注入，不会去匹配name。如果涉及到type无法辨别注入对象时，那需要依赖@Qualifier或@Primary注解一起来修饰。
在Mapper文件加入@Repository或@Component（以上两个注解与@Service、@Controller之间的区别、联系）
Lombok，@RequiredArgsConstructor(onConstructor = @__(@Autowired))

八编写用户微服务和内容微服务

1、开发分享详情查看页面：该页面涉及内容中心share表，同时也涉及用户中心的user表，适合微服务场景
在这里插入图片描述

PS：在实际开发中，对于核心业务，一定要设计好开发流程，分析业务过程中，除了业务流程图，还可能用到活动图、用例图等，便于理解，且易于与同事沟通，需重视建模，没有建模的微服务是没有灵魂的