1. 单体架构

以前的系统大多是各个业务系统集中在一个单体的代码包中，包括现在也有部分传统公司也使用单体式的架构。比如订单、支付、商品、登录等模块全部写在一个代码包中。很多企业都是打包成war包部署到tomcat中。如下图：
单体应用到微服务应用的转变 - 图1

1.1单体的优缺点

  • 优点：单体系统部署简单，只要达成一个包丢到web服务器即可

  • 缺点：代码耦合性较高、任一业务出问题都会导致其他模块不可用

    2.SOA架构

    服务导向式架构（SOA）是集成多个较大组件（一般是应用）的一种机制，它们将整体构成一个彼此协作的套件。一般来说，每个组件会从始至终执行一块完整的业务逻辑，通常包括完成整体大action所需的各种具体任务与功能。组件一般都是松耦合的，SOA尝试将应用集成，一般采用中央管理模式来确保各应用能够交互运作。如下图:
    单体应用到微服务应用的转变 - 图2
    上图实现的构架是对单体的演进，各个系统拆分开来，每个模块对应自己的数据库(mysql、oracle、MongoDB、redis等不限制)。服务之前的调度依赖dubbo或者dubbox

    2.1 SOA的优缺点

  • 优点：

  1. 易维护
    业务服务提供者和业务服务使用者的松散耦合关系及对开放标准的采用确保了该特性的实现。建立在以 SOA基础上的信息系统，当需求发生变化的时候，不需要修改提供业务服务的，只需要调整业务服务流程或者修改操作即可，整个应用系统维护也简单了。
  2. 可用性高
    服务提供者和服务使用者的松散耦合关系上得以发挥与体现。使用者无须了解提供者的具休实现细节
  3. 伸缩性提高
    服务提供者可以互相彼此独立地进行调整，以满足新的服务需求
  • 缺点：
  1. 过于依赖dubbo、ebs等总线控制，存在单点问题
  2. 涉及不同系统事务一致性问题（分布式相关后续会专门来说）
  3. 系统之间交互需要使用远程通信，接口开发增加工作量

    3.微服务架构

    微服务，关键其实不仅仅是微服务本身，而是系统要提供一套基础的架构，这种架构使得微服务可以独立的部署、运行、升级，不仅如此，这个系统架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。
    微服务提倡的理念团队间应该是 inter-operate, not integrate 。inter-operate是定义好系统的边界和接口，在一个团队内全栈，让团队自治，原因就是因为如果团队按照这样的方式组建，将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合能变弱，跨系统的沟通成本也就能降低。如下图：
    单体应用到微服务应用的转变 - 图3
    微服务之前的通信不像SOA架构模式中依赖dubbo、ebs等总线控制，系统之前可以点对点的互相负载均衡调用（平级关系），服务之前只需要了解对应的名称，不需要知道ip，应用支持水平拓展，通过网关控制系统访问和限流。