系统架构

1.单一应用架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。

问题：

• 代码耦合度高，开发维护困难
• 无法针对不同模块进行针对性优化
• 无法水平扩展
• 容错性差，并发能力差

---

2.垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。

优点：

• 系统拆分实现了流量分担，解决了并发问题
• 可以针对不同模块进行优化
• 方便水平扩展，负载均衡，容错性提高

缺点：

• 系统间相互独立，会有很多重复开发工作，影响开发效率（例如：都需要用到用户认证服务）

---

3.分布式服务架构

当垂直拆分的应用越来越多，可以将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心。

优点：

• 将基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率

缺点：

• 服务越来越多，需要管理每个服务的地址（例如，A需要调用B、C、D、E四个服务，便需要配置四个服务的地址）
• 调用关系错综复杂，难以理清依赖关系（上图可见）
• 服务过多，服务状态难以管理，无法根据服务情况动态管理（负载均衡的合理使用）

---

4.面向服务架构(SOA)

当服务越来越多，需增加一个调度中心来实现服务治理。

服务治理要做什么？

• 服务注册中心，实现服务自动注册和发现，无需人为记录服务地址
• 服务监控，使得服务调用透明化
• 服务状态监控等

缺点：

• 一般而言，SOA架构只专注于服务治理，但是若项目拆分成多个微服务，只做服务治理还远远不够。

---

5.微服务架构

微服务架构是一种使用一套小服务来开发单个应用的方式或途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是RESTFUL API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务可使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。

微服务的特点：

• 单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责
• 微：微服务的服务拆分粒度很小，例如一个用户管理或部门管理就可以作为一个服务。每个服务虽小，但“五脏俱全”。
• 面向服务：面向服务是说每个服务都要对外暴露Restful（参数是xml或json格式的http接口）风格服务接口API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供Restful的接口即可。
• 自治：自治是说服务间互相独立，互不干扰
  • 团队独立：每个服务都是一个独立的开发团队，人数不能过多。
  • 技术独立：因为是面向服务，提供Restful接口，使用什么技术没有别人干涉
  • 数据库分离：每个服务都使用自己的数据源
  • 部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护

微服务架构图：