1.单一应用架构
当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本。
问题:
- 代码耦合度高,开发维护困难
- 无法针对不同模块进行针对性优化
- 无法水平扩展
- 容错性差,并发能力差
2.垂直应用架构
当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率。
优点:
- 系统拆分实现了流量分担,解决了并发问题
- 可以针对不同模块进行优化
- 方便水平扩展,负载均衡,容错性提高
缺点:
- 系统间相互独立,会有很多重复开发工作,影响开发效率(例如:都需要用到用户认证服务)
3.分布式服务架构
当垂直拆分的应用越来越多,可以将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心。
优点:
- 将基础服务进行了抽取,系统间相互调用,提高了代码复用和开发效率
缺点:
- 服务越来越多,需要管理每个服务的地址(例如,A需要调用B、C、D、E四个服务,便需要配置四个服务的地址)
- 调用关系错综复杂,难以理清依赖关系(上图可见)
- 服务过多,服务状态难以管理,无法根据服务情况动态管理(负载均衡的合理使用)
4.面向服务架构(SOA)
当服务越来越多,需增加一个调度中心来实现服务治理。
服务治理要做什么?
- 服务注册中心,实现服务自动注册和发现,无需人为记录服务地址
- 服务监控,使得服务调用透明化
- 服务状态监控等
缺点:
- 一般而言,SOA架构只专注于服务治理,但是若项目拆分成多个微服务,只做服务治理还远远不够。
5.微服务架构
微服务架构是一种使用一套小服务来开发单个应用的方式或途径,每个服务运行在自己的进程中,并使用轻量级机制通信,通常是RESTFUL API,这些服务基于业务能力构建,并能够通过自动化部署机制来独立部署,这些服务可使用不同的编程语言实现,以及不同数据存储技术,并保持最低限度的集中式管理。
微服务的特点:
- 单一职责:微服务中每一个服务都对应唯一的业务能力,做到单一职责
- 微:微服务的服务拆分粒度很小,例如一个用户管理或部门管理就可以作为一个服务。每个服务虽小,但“五脏俱全”。
- 面向服务:面向服务是说每个服务都要对外暴露Restful(参数是xml或json格式的http接口)风格服务接口API。并不关心服务的技术实现,做到与平台和语言无关,也不限定用什么技术实现,只要提供Restful的接口即可。
- 自治:自治是说服务间互相独立,互不干扰
- 团队独立:每个服务都是一个独立的开发团队,人数不能过多。
- 技术独立:因为是面向服务,提供Restful接口,使用什么技术没有别人干涉
- 数据库分离:每个服务都使用自己的数据源
- 部署独立,服务间虽然有调用,但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件,可复用,可替换,降低耦合,易维护
微服务架构图: