互联网应用架构发展

前言

  • 随着互联网的发展,用户群体逐渐扩大,网站流量成倍增长,常规的框架已经无法满足请求的压力和业务的快速迭代,随之而来的就是架构的发展和完善。本文主要描述了互联网应用架构的发展

一、单体应用架构

  • 应用诞生之初,用户量和数据规模都相对较小,项目所有的功能模块都放在一个工程中编码、编译和打包,并且部署在一个应用服务器(tomcat或者weblogic)中。这种模式就是单体应用的架构
  • 优点:
    • 项目前期开发节奏快,团队成员少的时候能快速迭代
    • 架构简单:只需要借助IDE开发、调试
    • 易于测试:只需要通过单元测试或者浏览器完成
    • 易于部署:打包成单一的war包或者可执行的jar包放到应用服务器中启动
  • 缺点:
    • 随着功能不断迭代,单项目过大,代码杂乱,耦合严重,开发团队逐渐壮大以后,沟通成本变高。编译过慢等
    • 新增业务困难:在代码杂乱的系统中新增加业务,维护旧功能,学习成本高,新手上手慢
    • 核心业务和边缘业务混为一谈,出现问题相互影响。
  • 为了解决业务量上涨的问题,单体应用架构也进一步发展,比如应用集群化、使用Nigix进行负载均衡、增加文件服务器、增加缓存服务器、数据库集群化、读写分离等。虽然以上方法能应对高并发的情况,但仍然是单体应用架构。不能从根本上解决严重的缺点。

二、垂直应用架构

  • 为了避免核心业务和边缘业务混为一谈,简化项目代码,把项目进行垂直划分。做垂直划分的原则是基于项目现有的业务进行。核心目标是为了业务之间相互不影响,在研发团队壮大后可以调高效率,减少沟通成本
  • 优点:
    • 系统拆分实现了流量分担,解决了并发问题
    • 可以针对不同模块进行优化
    • 方便水平扩展,负载均衡,容错率提高
    • 系统相互独立,互不影响,新业务迭代更加高效
  • 缺点:
    • 服务之间需要相互调用,如果某服务端口或者ip地址发生变化,调用的系统需要手动修改
    • 搭建集群后,实现负载均衡比较复杂。如:内网负责,在迁移机器时会影响调用方的路由,导致线上故障
    • 服务调用不统一,接口协议不统一
    • 服务监控困难:除了依靠接口、进程的监控,调用的成功率、失败率、总耗时等都无法监控

三、SOA应用架构

  • 随着模块的增多,维护的成本也变高,一些通用的业务和模块重复的越来越多,为了解决接口协议不统一、服务无法监控、服务的负责均衡等问题。引入Alibaba开源的Dubbo,一款高性能、轻量级的开源Java RPC框架,提供三大核心能力:面向接口的远程方法调用,智能容错和负责均衡,服务自动注册和发现。
  • SOA (Service-Oriented Architecture),即面向服务的架构。根据实际业务,把系统拆分成合适的、独立部署的模块,模块之间相互独立。
  • 优点:
    • 分布式
    • 松耦合
    • 扩展灵活
    • 可重用
  • 缺点:
  • 服务抽取粒度较大
  • 服务调用方和提供方耦合度较高

四、微服务应用架构

  • 微服务架构是SOA架构的一种拓展,这种架构模式下拆分粒度更小、服务更独立。把应用拆分成为一个个微小的服务,不同的服务可以使用不同的开发语言和存储,服务之间往往通过Restful等轻量级通信。
  • 微服务架构强调的重点是:业务需要彻底的组件化和服务化。
  • 优点:
    • 微服务很小,便于特定业务功能的聚焦
    • 微服务很小,每个微服务都可以被一个小团队单独实施(开发、测试、部署、运维),团队合作一定程度解耦,便于实施敏捷开发
    • 微服务很小,便于重用和模块之间组装
    • 微服务很独立,不同的微服务可以使用不同语言开发,松耦合
    • 微服务架构下,更易于引入新技术
    • 微服务架构下,更好的实现DevOps开发运维一体化
  • 缺点:
    • 微服务架构下,分布式复杂难以管理,当服务数量增加,管理越来越复杂
    • 微服务架构下,分布式链路跟踪困难
  • 微服务架构与SOA架构对比
    • 区别:服务拆分粒度不同。
  • 微服务架构中的一些概念
    • 服务注册:服务提供者将所提供服务的信息(服务器IP和端口、服务访问协议等),注册/登记到注册中心
    • 服务发现:服务消费者能够从注册中心获取到较为实时的服务列表,然后根究一定的策略选择一个服务访问
    • 负载均衡:负载均衡即将请求压力分配到多个服务器(应用服务器、数据库服务器等),以此来提高服务的性能、可靠性。
    • 熔断:断路保护。微服务架构中,如果下游服务器因访问压力过大而响应变慢或失败,上游服务为了保护系统整体可用性,可以暂时切断对下游服务的调用。这种牺牲局部,保全整体的措施就叫做熔断
    • 链路追踪:微服务架构越发流行,一个项目往往拆分成很多个服务,那么一次请求就需要涉及到很多个服务。不同微服务可能由不同团队开发、可能使用不同的编程语言实现、整个项目也有可能部署在很多服务器上,横跨多个不同的数据中心。所谓链路追踪,就是对一次请求涉及到的多个服务器进行日志记录、性能监控。
    • API网关:
      • 微服务架构下,不同的微服务往往会有不同的访问地址,客户端可能需要调用多个服务的接口才能完成一个业务需求,如果客户端之间与各微服务通信可能出现一下问题:
      1. 客户端需要调用不同的url地址,增加了维护调用难度
      2. 在一定的场景下,存在跨域请求问题
      3. 每个微服务都需要独立的身份认证
      • API网关可以统一处理上述问题,API请求调用统一接入API网关层,由网关转发请求。API网关更关注在安全、路由、流量等问题。功能如下:
      1. 统一接入(路由)
      2. 安全防护(统一鉴权,负责网关访问身份认证验证等)
      3. 黑白名单(实现通过IP地址控制禁止访问网关功能,控制访问)
      4. 协议适配(实现通信协议校验、适配转换功能)
      5. 流量控制(限流)
      6. 长短链接支持
      7. 容错能力(负责均衡)

你可能感兴趣的:(笔记,微服务,微服务)