单体架构的总结

把项目打包时，需要安装JDK
可以在控制台中输入mvn clean package -DskipTests中进行打包
这种方法是跳过测试，如果不加-DskipTests则时需要测试
也可以在java的编写软件中来进行编写，如果是StS则可以在mavan中进行打包，打包的jar包在target中，你就可以有jar包和本地数据库就可以运行该项目了
进行springbootActuator健康监测是可以在配置中
managenent.port=8085这是设置下健康监测的端口号
management.security.enabled这个注解是是否授权的问题
endpoints.shutdown.enabled
在原生端点中，只提供了一个用来关闭应用的端点：/shutdown。我们可以通过如下配置开启它：
endpoints.shutdown.enabled=true
在配置了上述属性之后，只需要访问该应用的/shutdown端点就能实现关闭该应用的远程操作。由于开放关闭应用的操作本身是一件非常危险的事，所以真正在线上使用的时候，我们需要对其加入一定的保护机制，比如：定制Actuator的端点路径、整合Spring Security进行安全校验等。

单体架构的优势

1. 便于开发：只需借助IDE的开发、调试功能即可完成
2. 易于测试：只需要通过单元测试或浏览器即可完成测试
3. 易于部署：打包成单一可执行jar包，执行jar包即可完成部署

单体架构的不足

1. 复杂性高：因为项目已经成熟，不易修改，就是没人理解整个代码的整体逻辑
   - 代码难以理解
   - 难以理解导致代码质量低，复杂性进一步增加
   - 代码难以被修改和重构
2. 交付效率低
   - 构建和部署耗时长，难以定位问题，开发效率低
   - 代码复杂和变更影响难以理解，需要数天完成全量测试
   - 全量部署耗时长、影响范围广、风险大、发布频率次低
3. 伸缩性（scalable）差
   - 单体只能按整体横向扩展，无法分模块垂直扩展
   - IO密集型模块和CPU密集型模块无法独立升级和扩充
4. 可靠性差
   - 一个bug有可能引起整个应用的崩溃
5. 阻碍技术创新
   - 受技术栈限制，团队成员使用同一框架和语言
   - 升级和变革技术框架变得困难
   - 尝试新语言变得困难

微服务架构介绍

微服务架构:将单体应用拆分为多个高内聚低耦合的小型服务，每个小服务运行在独立进程，由不同的团队开发和维护，服务间采用轻量级通信机制，独立自动部署，可以采用不同的语言及储存

微服务的优势

1. 独立部署
   - 一个微服务的修改不需要协调其他服务
2. 伸缩性强
   - 每个服务都可以在横向和纵向上扩展
   - 每个服务都可按硬件资源的需求进行独立扩充
3. 与组织架构相匹配
   • 微服务架构可以更好将架构和组织相匹配
   • 每个团队独立负责某些服务，获得更高的生产力
4. 技术异构性
   • 使用最适合该服务的技术
   • 降低尝试新技术的成本