单体架构的总结

把项目打包时,需要安装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. 技术异构性
    • 使用最适合该服务的技术
    • 降低尝试新技术的成本
      在这里插入图片描述
展开阅读全文

没有更多推荐了,返回首页