01-Web技术架构演变
1. Web1.0阶段
单宽不足,项目内容少,用户量少。
单体架构 |
---|
单体架构(Monolithic)
“单体”只是表明系统中主要的过程调用都是进程内调用,不会发生进程间通信,仅此而已。
单体意味着自包含。单体应用描述了一种由同一技术平台的不同组件构成的单层软件。
2. Web2.0阶段
带宽提速,用户量增加,门户网站活跃,项目考虑安全性和稳定性。
单体架构搭建集群 |
---|
SOA 架构(Service-Oriented Architecture)
面向服务的架构是一次具体地、系统性地成功解决分布式服务主要问题的架构模式。
三种比较代表性的架构模式:
- 烟囱式架构 (Information Silo Architecture):信息烟囱又名信息孤岛(Information Island),它指的是一种完全不与其他相关信息系统进行互操作或者协调工作的设计模式。
- 微内核架构 (Microkernel Architecture):微内核架构也被称为插件式架构(Plug-in Architecture)。
- 事件驱动架构 (Event-Driven Architecture):为了能让子系统互相通信,一种可行的方案是在子系统之间建立一套事件队列管道(Event Queues),来自系统外部的消息将以事件的形式发送至管道中,各个子系统从管道里获取自己感兴趣、能够处理的事件消息。
3. 搭建集群后的问题
Nginx
- 解决用户请求平均分发(并发问题)Redis
- 解决数据共享并实现缓存功能(数据共享问题)ElasticSearch
- 解决搜索数据的功能(搜索问题)
插入中间件 |
---|
4. 垂直架构
项目包含用户模块,商品模块,订单模块… 模块 + 集群。
垂直架构图 |
---|
微服务架构(Microservices)
微服务是一种通过多个小型服务组合来构建单个应用的架构风格,这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言,不同的数据存储技术,运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。
微服务是一种软件开发技术,是一种 SOA 的变体形式。
九个核心的业务和技术特征:
- 围绕业务能力构建(Organized around Business Capability)
- 分散治理(Decentralized Governance)
- 通过服务来实现独立自治的组件(Componentization via Services)
- 产品化思维(Products not Projects)
- 数据去中心化(Decentralized Data Management)
- 强终端弱管道(Smart Endpoint and Dumb Pipe)
- 容错性设计(Design for Failure)
- 演进式设计(Evolutionary Design)
- 基础设施自动化(Infrastructure Automation)
5. 分布式架构
垂直架构 –> 分布式架构。
分布式架构常用方式:
Dubbo
- RPC(通讯方式)SpringCloud
- HTTP(通讯方式)
分布式架构图 |
---|
6. 服务之间异步通讯
为了实现分布式架构中服务之间的异步通讯,需要使用 RabbitMQ 等消息队列中间件。
分布式架构下,实现异步通讯 |
---|
7. 服务之间地址维护
由于服务越来越多,每个服务的访问地址都是一样的:协议://地址:端口号/路径
需要使用以下技术:
Eureka
- 注册中心帮助管理服务信息Robbin
- 可以帮实现服务之间的负载均衡
Eureka 实现通讯地址维护,Robbin 实现服务之间的负载均衡 |
---|
8. 服务降级
Hystrix
提供了线程池隔离的方式,避免服务器线程池耗尽,在一个服务无法使用时,还提供断路器的方式来处理问题服务,从而执行降级方法,返回托底数据。
Eureka,Robbin,Hystrix 都是 SpringCloud 技术栈中的组件。
使用Hystrix帮提供断路器和隔离,并最终服务降级 |
---|
9. 海量数据
解决海量数据高并发的问题,可以基于 MyCat
实现数据库的分库分表。
基于MyCat实现分库分表 |
---|
10. 微服务架构
在单独模块中再次拆分项目的方式称之为微服务架构,微服务架构也是分布式架构。
比如压力最大的商品模块,拆分为 商品模块 + 查询商品模块
微服务架构,在分布式架构的基础上再次拆分 |
---|
后微服务时代(Cloud Native)
从软件层面独力应对微服务架构问题,发展到软、硬一体,合力应对架构问题的时代,此即为“后微服务时代”。
11. 模块过多问题
为了解决模块过多,运维成本增加的问题,采用 Docker
容器化技术来帮助管理各个模块的部署,还可以通过CI、CD持续集成,持续交付,持续部署。
Docker容器化技术 |
---|
12. 分布式事务
最传统的操作事务的方式,是通过 Connection 链接对象的方式操作,Spring 也提供了声明式事务的操作。
为了解决事务的问题,使用 RabbitMQ
或者 LCN
等方式来解决。
13. 分布式锁
传统的锁方式,synchronized | Lock锁,在分布式环境下,传统的锁是没有效果的。
为了解决锁的问题,使用 Redis
或者 Zookeeper
来解决。
14. 分布式任务
在传统的定时任务下,由于分布式环境的问题,可能会造成任务重复执行,一个比较大的任务,需要可以拆分。
为了解决任务问题,使用 Redis + Quartz
或者 Elastic-Job
来解决。
未来: 无服务时代
无服务架构(Serverless)
如果说微服务架构是分布式系统这条路的极致,那无服务架构,也许就是“不分布式”的云端系统这条路的起点。
主要包含2点:
- 后端设施(Backend)
- 指数据库、消息队列、日志、存储,等等这一类用于支撑业务逻辑运行,但本身无业务含义的技术组件,这些后端设施都运行在云中。
- 后端即服务(Backend as a Service,BaaS)
- 函数(Function)
- 指业务逻辑代码,这里函数的概念与粒度,都已经很接近于程序编码角度的函数了,其区别是无服务中的函数运行在云端,不必考虑算力问题,不必考虑容量规划。
- 函数即服务(Function as a Service,FaaS)
无服务的愿景
是让开发者只需要纯粹地关注业务,不需要考虑技术组件,后端的技术组件是现成的,可以直接取用,没有采购、版权和选型的烦恼;不需要考虑如何部署,部署过程完全是托管到云端的,工作由云端自动完成;不需要考虑算力,有整个数据中心支撑,算力可以认为是无限的;也不需要操心运维,维护系统持续平稳运行是云计算服务商的责任而不再是开发者的责任。