业务架构

单体模式

早期系统多以单体业务为主，逐个业务线扩张。系统也多呈现为多个mvc独立运行状态。比如很多服务部署在一个tomcat上，这样当一个地方出问题，整个系统都用不了了。

特点

1. 粒度较粗：纯以业务为导向，往往形成业务团队各自为战，新业务线出现时疯狂扩张
2. 重复开发：相同功能可能在不同业务的项目中被重复开发，比如短信发送、支付、财务统计

中台战略

概述：

中台在2015由阿里提出，其实是阿里共享业务技术部的成型过程。
中台不是什么新奇东西，实际上是“共享“理念在业务、系统、组织架构上的一种落地与实施。

中台的出现解决了单体模式的一些问题，例如重复开发等。

案例：

以经典电商中台划分为例：

业务中台

业务中台基于公共服务的沉淀，把一些可能用到的公共业务单独抽取成一个项目。
这些服务在 B2B，B2C 等系统中都会具备，是相同的。

例如：

商品中心：商品、类目、sku、spu
交易中心：订单、状态流转、条目、支付
营销中心：促销、优惠券、活动
会员中心：账户、基本信息、收发货地址、商铺商家信息
仓储中心：仓库、库存
物流中心：发货信息、自主物流或外部物流对接

技术中台

与业务无关的基础沉淀，技术类内容可以在各个团队之间共享。
基础架构：核心类库、公共框架、基础服务、服务治理框架
中间件：分布式缓存、分布式消息、数据存储（db，nosql）、分布式文件、分布式调度
自动化运维：监控中心、资源管理、配置中心、发布中心、日志平台
自动化测试：任务协同、基础测试、性能测试、接口测试、持续集成
（有的公司会抽取一个运维中台，将开发层和系统层的内容分开）

数据中台

数据中台不是数据平台，也不是数据仓库，这三者是有区别的。数据中台主要抽取了一些对数据进行分析的业务，比如推荐系统。数据中台不是用来存储数据的。
举个例子：数据平台可以理解为数据库，数据仓库类比为报表。
而数据中台更贴近上层业务，带着业务属性。同样以接口形式为其他上层各个业务线提供持续调用。
数据抽取：从db，nosql，日志等各个来源提供抽取接口
数据接口：为上层业务提供需要的定制化业务数据接口
数据分析：行业分析与决策、数据驱动运营
人工智能：用户画像、商品推荐
可视化：数据大屏、信息展示、活动报表等

服务接入层

即大中台，小前台，电商中直面用户的B2B,B2C等各个业务线。

这可以理解为我有很多中台，组合成一个大中台，供前台调用。假如我现在要开发一个商城，我只要开发给用户看的页面/app，这就是小前台。我们真正用到的服务直接去调用大中台的业务中台或者数据中台等等。

数据架构

单数据库

java web项目直接通过jdbc，连接单一的数据库，读写扎堆在一块，单库上的机器io及cpu性能很快达到上限

主从读写

java web应用层连接多个数据库，数据库之间形成主从关系，主库上写，从库上读。读写压力被分散。

问题：

数据延迟：从主库到从库之间数据需要经过网络传输，不可避免的有延迟
开发层面：需要开发框架具备多数据源的支持，以及自动化的数据源切换
单库瓶颈：业务越来越多，表数量越来越多。出现单个库几百张表的现象
数据局限：依然无法解决单表大数据的问题，比如订单积累达到亿级，即使在从库，关联查询依然奇慢
无比

分库分表

方案：
主从库的写入依然是有一个统一的主库入口。随着业务量的提升，继续细粒度化拆分
业务分库：订单库，产品库，活动库，会员库
横向分表：（拆记录）3个月内订单，半年内订单，更多订单
纵向分表：（拆字段）name、phone一张表，info、address一张表，俩表id一致

问题：
分库：不同的数据库，所以无法使用数据库事务，而分布式事务的效果并不理想，多采用幂等和最终一
致性方案。
分表：拆了再聚合是一对矛盾，例如按下单时间维度的分表，需要按用户排序统计变得异常困难。

高速缓存

数据库往往是系统的瓶颈，根据数据的冷热划分，热点数据如类目、商品基础信息放在缓存中，其他数
据延迟加载。

问题：
缓存策略：冷热数据的存放，缓存与db的边界需要架构师去把控，重度依赖可能引发问题
（memcache造成db高压案例；redis短信平台故障案例）
缓存陷阱：穿透（不存在的 key），雪崩（多个 key 同时过期）
数据一致性：缓存和 db 之间因为同一份数据保存了两份，自然带来了一致性问题

数据多样化

一个网站中，数据库和缓存只是一种基本的存储手段，除了这些，随着网站架构的发展其他各种形式的
存储结构相继涌现：数据库全文检索→搜索引擎、本地上传+nfs→分布式文件系统的演进等等。。

问题：

开发框架支持：存储的数据多样化，要求开发框架架构层面要提供多样化的支撑，并确保访问易用性

数据运维：多种数据服务器对运维的要求提升，机器的数据维护与灾备工作量加大
数据安全：多种数据存储的权限，授权与访问隔离需要注意

应用架构

单机调优

早年间的项目大多采用mvc开发。所有的东西都耦合在一个项目里。

缺点：

1. 每个项目成一个mvc结构，部署在应用服务器上。
2. 随着业务扩张，需求迭代，项目变得越来越大，一个war包动辄几百兆。

动静分离

静态响应：tomcat对静态文件响应一般，提取静态文件，直接由nginx响应。
动态代理：后端api通过代理转发给tomcat应用机器。

缺点：

1. 开发层面调整：项目结构要同步调整，由原来的一体化mvc转换为后端api+前端形式。
2. 前后协调：前后端的分工变得更明确，互相并行开发，独立部署，但也带来了接口协调与约定等沟通问题
3. 跨域问题：后段与前端如果域名不同，可能存在跨域问题（head头，jsonp等手段可以解决）。

分布式

单纯的动静分离只解决了自己服务的项目结构，跨项目接口调用时，必须经过rest请求，不利于服务之
间的交互。所以就出现了分布式。其核心思想为公共服务 ：重复开发的基础服务提取到一个单独的项目，形成服务中心，避免重复造轮子，降低成本

缺点：

1. 界限把控：服务的粒度、拆分和公共服务提炼需要架构师的全局把控。设计不好容易引发混乱
2. 部署升级：服务数量增多，人工部署变的不现实，必须借助自动化运维
3. 服务可用性：抽调的微服务因需要被多个上层业务共享，可用性等级变高，一旦宕机就是灾难
4. 熔断和限流：做好服务熔断和限流，提防服务单点瓶颈造成整个系统瘫痪。

微服务

微服务是基于SOA思想，将系统粒度进一步细化而诞生的一种手段。其实就是在分布式的基础上更加细化了而已。比如有多个服务，分布式可能共用一个数据库，微服务可能拆分成一个服务一个数据库

缺点：

1. 服务拆分：粒度并非越小越好。太小会带来部署维护等一系列成本的上升。
2. 接口约束：系统增多，各个服务接口的规范化日益重要，要求有统一的服务接口规范，推动企业消息总线的建设
3. 权限约束：接口不是任意想调就可以调的，做好权限控制，借助oauth2等手段，实现服务之间的权限认证。

部署架构

单机器

小型网站，阿里云小项目还有人在用。部署简单：采用web包部署与发布，db等资源同台机器连接，简单易操作。

缺点：

资源争夺：在业务发展的初始阶段尚可支撑，随着访问量的上升，单机性能很快会成为系统瓶颈。

角色划分

稍微大一点的系统，把数据库、缓存、消息等中间件剥离出去，单独机器来部署。

方案：

1. 多台机器：tomcat与mysql各自独占机器资源
2. 针对性扩容：tomcat应用机更注重cpu的运算和内存，mysql更注重io与磁盘性能，针对各自情况扩容

缺点：

数据安全：需要跨机器访问数据库，链接密码需要注意防范泄漏

应用集群

单点系统容易出现故障，所以采用了集群的方式来保证高可用。

方案：

• apache：早期负载均衡方案，性能一般
• nginx：7层代理，性能强悍，配置简洁，当前不二之选
• haproxy：性能同样可靠，可做7层或4层代理。
• lvs：4层代理，性能最强，linux集成，配置麻烦
• f5：4层，硬件负载，财大气粗的不二选择

缺点：

1. session保持：集群环境下，用户登陆需要分布式session做支撑
2. 分布式协同：分布式环境下对资源的加锁要超出线程锁的范畴，上升为分布式锁
3. 调度问题：调度程序不能多台部署，容易跑重复，除非使用分布式调度，如elastic-job
4. 机器状态管理：多台应用机的状态检测与替换需要做到及时性，一般niginx层做故障转移
5. 日志管理：日志文件分散在各个机器，促进集中式日志平台的产生

多层代理

机器规模进一步加大，动静态均有多个nginx负载，入口统一交给lvs负载。多层代理形成。

缺点：

机房受限：lvs依然是单一节点，即使keepalived做到高可用，流量仍然需要在唯一入口进入。

异地访问

将相同的系统部署多份，分散到异地多个机房，或者电信、移动等多个网络中。不同地点，不同网络接入的用户，有了不同的访问入口和选择。

方案：
dns轮询：通过配置多个ip将服务部署到多个机房，通过dns的策略轮询调用，可以实现机房层面的扩容
CDN：就近原则，使用户获得就近的机房访问相关资源，自己投资太大，购买他方需要付费。

缺点：

基本解决了机器部署的扩容问题，随着业务的发展，扩容与收缩变得困难，促进资源调度层面的技术发
展。

云平台

针对中台化的建设及微服务数量的飙升，部署和运维支撑同步进行着变革。面临微服务的快速部署，资源的弹性伸缩等挑战，容器化与云被推进。

案例：成百上千的服务数量庞大、大促期间某些微服务的临时扩容。

方案：

• 虚拟化：vm方案，Openstack，Vmware，VirtualBox
• 容器化：docker
• 编排：swarm，k8s，k3s（课题：运维篇 docker，k8s深入原理与应用）
• 云化：容器化解决了资源的快速伸缩，但仍需要企业自备大量机器资源。推动私有云到企业云进化

缺点：

1. 资源预估：注意资源的回收，降低资源闲置和浪费，例如大促结束后要及时回收。
2. 运维要求：需要运维层面的高度支撑，门槛比较高
3. 预估风险：云瘫痪的故障造成的损失不可估量

最后

以上就是包容可乐为你收集整理的互联网架构演变过程业务架构数据架构应用架构部署架构的全部内容，希望文章能够帮你解决互联网架构演变过程业务架构数据架构应用架构部署架构所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。