单体架构的优缺点

优点：

• 部署简单：只有一个包

• 技术单一：同一个架构来说，基本上是一个一种技术，类似springboot + java

• 用人成本低：因为只需要一种技术

缺点：

• 代码结构混乱：业务复杂，导致代码量很大，管理会越来越困难。

• 开发效率低：开发人员同时维护同一套代码，很难避免代码冲突。开发过程中会伴随解决冲突，严重影响开发效率。

• 排查解决问题成本高：线上发现了bug，可能bu g很简单，但是由于只有一套代码，需要编译打包上线，成本很高。

• 监控很难：很多功能点，杂在一个系统中。

微服务

• 由很多服务组成，每个服务都可以独立部署，每个服务之间以一种轻量级的通讯方式进行交互，例如http。这些服务之间没有很强的技术关联，可以A用java，B用Go.
• 设计原则：
  • 拆分足够的微。颗粒太大，没法发挥微服务的优势，颗粒太小，管理混乱。
  • 轻量级通信。rest，消息中间件
  • 领域驱动原则。比如客户是一个领域，表单是一个领域
  • 单一指责。服务应该尽可能不依赖其他服务，边界应该足够清晰，而且接口应该妥善设计，隐藏内部细节。
  • DevOps
  • 不限技术栈。比如mongo, pg
• 如何设计：
  • 服务拆分
  • 服务注册。多个服务间的通信，需要一个服务注册机制。服务启动的时候，要将服务注册到注册中心；服务中心和微服务之间通过某种机制关联，例如心跳机制；不同服务之间可以进行发现，从服务注册中心，获取要调用的服务的信息。
  • 服务消费，调用其他服务，调用方相当于是服务消费者，被调用方是服务供应商
  • 统一入口，服务数量多起来之后，每一个消费者要记住所有服务的名称是比较困难的，所以需要一个统一的入口，我们只需要知道入口的名称，而不需要知道具体服务提供者的名称。
  • 配置的管理。配置文件里写上不同服务需要的配置，不同服务去做个性化配置。
  • 熔断机制：某个微服务出现异常时（请求反应慢或宕机），其整个流程还是可以友好的进行下去。即向调用方返回一个符合预期的、可处理的备选响应(FallBack)，而不是长时间的等待或者抛出调用方无法处理的异常，这样就可以保证调用方的线程不会被长时间、无厘头滴占用，从而保护整个系统，避免崩溃。
  • 自动扩展：服务可以根据当前附在状况可以自动扩展。比如当前有10个实例，当负荷突然增大，比如请求数增大，可以自动扩展成20个。
• 拆分的意义
  • 易于实现：服务更小，代码更少，更加利于理解，实现。
  • 易于维护：更少的代码，更容易维护
  • 易于部署：每个服务都是轻量级实现，jar包比较小
  • 易于更新：服务之间都是隔离的，所以每个服务都可以独立更新，不会影响其他服务。
• 拆分的方法
  • 横向拆分。数据采集，数据存储，数据查询，数据展示
  • 纵向拆分。基础设施层，领域层，应用层，用户界面
  • 使用DDD。不同的领域