系统架构的演变

最早期集中式架构阶段

• 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是影响项目开发的关键。
• 引发的问题问题
  • 单点故障问题(一台服务器挂掉，全都访问不了了)
  • 并发数低
  • 代码的耦合度高(你调用了我，我调用了你)
  • 不方便扩展 (比如某几个模块的并发程度高，要么整个都扩展要么都不)

水平切分工程(分层 web service mapper)

• 切分成一个Web工程，一个Service工程，一个Map工程，一个pojo 一个数据库…
• 与上面那个没啥区别，还是打成一个war包一起运行的

垂直拆分(功能拆分)阶段 – 最早的分布式架构

• 当访问量逐渐增大，单一应用无法满足需求，此时为了应对更高的并发和业务需求，根据业务功能对系统进行拆分：
  
• 解决了的问题(可以布多个tomcat了)
  • 系统拆分实现了流量分担，解决了并发问题
  • 可以针对不同模块进行优化
  • 方便水平扩展，负载均衡，容错率提高
• 引发的问题
  • 系统间相互独立，会有很多重复开发工作，影响开发效率

分布式服务阶段

• 对不同的用户模块进行拆分(比如用户管理是一个独立的服务，独立的tomcat容器。订单…)
• 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式调用是关键。
  
• 解决了的问题
  • 将基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率
• 引发的问题
  • 系统间耦合度变高，调用关系错综复杂，难以维护

流动计算架构SOA阶段 – 面向服务

• 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键
• 中间有一个注册中心 = 容器 。先把容器启动起来，在启动其他微服务的时候，就会把自己注入到容器里
  
• 服务治理要做什么？
  • 服务注册中心，实现服务自动注册和发现，无需人为记录服务地址
  • 服务自动订阅，服务列表自动推送，服务调用透明化，无需关心依赖关系
  • 动态监控服务状态监控报告，人为控制服务状态
• 缺点：
  • 服务间会有依赖关系，一旦某个环节出错会影响较大
  • 服务关系复杂，运维、测试部署困难，不符合DevOps思想

微服务阶段

• 单一职责：每个服务都对应唯一的业务能力，做到单一职责
• 微：微服务的服务拆分粒度很小
• 面向服务：每个服务都要对外暴露rest风格服务接口API
• 自治：服务间互相独立互不干扰