文章目录
- 一、互联网架构总体概览
- 二、互联网架构的演进过程
- 写在后面
一、互联网架构总体概览
随着互联网不断快速的发展，从传统的内容推广、信息交互、数据挖掘、人机交互，最终到万物互联互通，总共已经历了如下4个阶段，而每个阶段，给互联网技术支撑架构带来了什么样的变化呢？这个是我们值得思考的，而本质的变化量是什么？
答案数据是本质。
管理数据的方案则称之为管理架构体系，随着数据之间的关系关联性不断延伸，则管理的本质也随着发生演化。
目前互联网总共经历了如下四个阶段：
1.互联网1.0阶段完成了传统广告业数据化（三大门户网站）（数据提取与展示-PGC）
2.互联网2.0阶段完成了内容产业数据化-用户粘性（微博、twitter、instagram、qq农场、开心农场）（数据关系、分析-UGC）
3.移动互联网阶段完成了生活服务业数据化（qq、微信、陌陌、facebook、抖音、钉钉、短视频、直播平台）
4.万联网阶段，就是万物皆可相连，一切皆被数据化（智能家具、智能制造）
其实，当前环境下，万联网阶段还有很长的路要走。
互联网架构设计演进原因
单体架构已经无法支撑目前的需求了。
功能越来越复杂（需要更大的算力）、
数据量越来越大、
请求越来越密集、
业务迭代速度越来越快、
服务规模越来越庞大
架构设计的本质
不管什么样的技术架构，能够使业务产品快速迭代，持续交互才是王道。
降本提效。（降低人力与机器成本；提高开发、测试、运维效率；为什么不用单体而使用微服务目的就是快速迭代与快速交付）
业务越来越多，数据量越来越大，用户体验度越来越高，对架构带来了很大的挑战。
重要的一点就是：架构演进由需求驱动。
也就是，技术永远都是来为了适应当前的业务的。
架构演进的过程
① 单体架构（monoliths）
② 水平分层架构（Horizontal layered）
③ 集群架构（Cluster Architecture）
④ 面向服务架构（Service Oriented Architecture）-技术通信模式：单服务总线
⑤ 微服务架构（MicroService）- 技术通信模式：P2P模式
⑥ 服务网格架构（Service Mesh）-isito
⑦ 无服务化架构（ServerLess）-（技术下沉）事件（事件数据）
也就是说，架构演进的核心就是——分而治之。
架构的演进的驱使，就是数据的驱使，对数据的处理。
二、互联网架构的演进过程
1、单体架构
初期单体的优势：
开发简单、测试流程与环境简单、手动部署或简单脚本部署、整体伸缩容易、问题跟踪快速、问题修复高效、业务拆分分包、业务调用直接等等。
单体架构适应所有的初期产品，功能简单，用户量少。
但是随着客户端及用户的增多，单体架构或许还会演变成如下架构：
注：浏览器、手机浏览器wap/H5、安卓APP、苹果APP、小程序（应用内程序，快应用，轻量级应用，业务平台数据隔离）、window&MAC&PAD客户端、广告电子终端、电视&移动大屏&智能终端、智能机器人、智能穿戴设备（+大数据+AI+边缘计算），这些都属于客户端。
当普通单体架构已经支撑不了日渐庞大的用户量时，就需要做集群了。
单体架构的痛点
随着业务的增加，复杂应用的开发维护成本变高，部署效率逐渐降低。
团队协作效率差，公共模块功能重复开发。
系统可靠性变差（内存泄漏、访问量逐渐攀升，网络流量增加，数据库面临巨大压力）。
维护与定制困难（业务代码不断膨胀，功能越来越复杂）。
新功能上线周期变长（公共API变更导致策略工作量剧增、新特性无法独立部署和交付）。
后期单体架构的弊端：
- 代码重复量高
- 需求变更困难
- 代码维护难度高
- 部署效率低
- 新需求上线周期长
- 技术选型单一
- 系统耦合性高
- 开发效率越来越低
单体架构设计与业务分析
对于这样一个系统，随着使用产品的用户越来越多，网站的流量会增加，最终单台服务器无法处理那么大的流量，此时就需要用分而治之的思想来解决问题。
抗流思路：
① 首先尝试通过简单扩容来解决。
② 其次通过物理垂直扩容，CPU32核提升CPU64核，内存64GB升级到256GB，随机读写量从HDD升级到SSD或通过RAID卡来提升吞吐量，网卡百兆提升千兆或万兆。
③ 水平扩容（大颗粒），搞不定，就需要水平拆分数据/应用来提升系统的伸缩性。
优异性选择
异步快还是同步快？
如果同步调用的RT（Reaction Time响应时间）比较高，那么该情况下异步性能更高。
异步会消耗更多的内存与CPU（线程、切换），所以一定要慎用。
当单线程业务中有大量阻塞问题，就可以选择异步。
单体快（小规模）还是集群（中型规模）或是微服务（大型规模）？
根据业务面积，来选择服务规模。加入在单体中能够解决业务性能问题，单体架构比任何架构都要快。
“杀鸡不用宰牛刀”
2、水平分层架构
针对单体架构，进行二次提升，对大颗粒服务进行拆分。
（1）垂直拆分
垂直方向拆分，一般就是使用DDD的思想，将业务拆分为多模块。
比如说，用户、交易、商品、库存、积分、促销等等模块。
（2）水平拆分
水平方向拆分，一般就是技术上的拆分。
① 网关层
一般用于认证和安全、性能监测、动态路由、负载分配。
② web服务层
进行业务数据组织、视图内容的转换。
③ 业务逻辑层
做业务逻辑的判断，只负责业务数据的处理，不关心业务数据的来源，对业务数据来源进行透明化。
④ 数据访问层
mysql、redis、hbase、mongodb等等所有数据存储，进行数据持久化。
屏蔽底层存储的差异性。
不同服务由独立进程管理，从性能上可以做服务的读写分离，分为读服务和写服务。
⑤ 数据库层
可以选择垂直拆分（分库）、水平拆分（分表）。
主流技术产品：MyCat、sharding jdbc（使用代理）。
每一层可以用独立的开发语言进行开发，并且通过rpc方式进行远程方法调用。
（3）解决垂直架构问题
将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速地响应多变的市场需求。通过隔离性的特征来保障核心服务的稳定性。
将公共API抽取出来，作为独立的公共服务提供其他调用者消费，以实现服务的共享与重用，降低开发与维护成本。
应用拆分之后按照模块独立部署，接口调用由本地API演进成跨进程的远程访问，这时RPC框架应运而生。
（4）同步架构与异步架构
异步架构相比较同步架构而言，在WEB层和逻辑层之间，加了一个MQ，将请求操作缓存慢慢消化，返回用户一个中间状态，增加系统的吞吐量，适合在高并发场景下使用。
异步架构的问题：请求路径过长，响应时间变高，定位问题复杂化，运维成本变高。
每一层之间通过RPC或者REST进行远程调用。
在APP/Browser等客户端访问Nginx时，可以加上DNS/CND实现异地多活。
3、面向服务的架构（SOA）
SOA的重点关注的是服务可重用性。
（1）SOA定义
SOA是一种粗颗粒、松耦合的以服务为中心的架构，接口之间通过定义明确的协议和接口进行通信。
SOA帮助企业架构师以更快速、可靠和可重用的形式规划整个业务系统，相比传统非服务化架构，SOA更加从容地应对复杂企业系统集成和需求的快速变化。
接口采用中立的方式进行定义，独立于硬件平台、操作系统和编程语言（SOAP、WSDL、XML等通用语言）。
SOA支持多种协议（HTTP、REST API、JSM、TCP SOCKET、EJB、COM/DCOM、WebService），因为大公司的历史遗留问题，存在多种不同的技术栈（C、C++、PHP、Java、GO、Elange、Python），并且不同的协议具有特定场景的优势。
（2）SOA架构图
（3）ESB框架结构
比如说，一个C语言开发的支持HTTP协议的订单服务，需要调用Java开发的支持TCP的商品服务，就有这样一个流程：
订单服务 -> ESB（接收http数据） -> ESB（适配器转换为TCP数据） -> ESB前置路由器 -> 商品服务 ->ESB后置路由器 -> ESB（适配器转换为http数据） ->订单服务
前置路由器一般包括：
幂等路由器（防止重复消息消费）、条件路由器（过滤服务本业务组件的消息）、聚合路由器（将请求结合再进行转发）、排序路由器（请求排序）、转发路由器。
后置路由器一般包括：
过滤路由器（为一个组件配置多个过滤路由器，各自路由器可根据自己的业务规则进行过滤，判断消息内容是否通过本路由器进行转发）、多播路由器（将消息转发给多个不同的目标地址）、消息分割路由器、多选一路由器（LB负载均衡）、链路由器（前一个消息的输出作为后一个消息的输入）。
（4）SOA的特点
SOA旨在重用已有的IT资产，对不同的异构服务进行灵活互通。相当于使用垂直拆分的方式，通过消息适配器、路由器和业务组件，将各个服务串联。
SOA架构中，业务垂直方向拆分，每个服务还是一个单体，颗粒度比较大。并且一个致命问题：对ESB总线依赖严重。
4、微服务架构
（1）什么是微服务架构
1.由一组小服务组成的应用，这一组服务往往提供特定的业务能力。（业务角度，DDD，服务自治）
2.往往拥有自己独占的进程，通过轻量级的通讯协议进行通讯，比如http。（颠覆已有的技术，进入大规模服务化的流程。技术角度，RD，RPC）
3.能够独立部署，并且具有完全的自动化的部署能力。（服务无感知，滚动升级，灰度发布，运维角度）
4.极小化的集中式的服务管理能力。（平台级的管控能力 ）
5.可以使用任何的开发语言和数据库技术。（技术多样性，技术选型）
（2）为什么选择微服务架构
1.快速发布迭代的能力
2.细粒度独立发布迭代的能力
3.对多版本的天然支持
4.标准化的描述和调用方法
5.基于业务进行抽象的接口
6.基于服务的横向扩展
（3）大中台思想
大中台对技术平台的需求：
1.用户可以在线随时获得服务（7*24）
2.业务可以快速创新和试错（周迭代）
3.团队可以并行协同工作，方便快速地与场景或合作伙伴互联。
4.可以支撑海量用户访问。
5.业务自动化，可以感知线上情况可以在线管控和调整业务。
6.数据资产积累及决策支持，丰富的智能化应用场景。
业务中台与数据中台建设的基本思路：
1.业务中台围绕核心竞争力-客户运营、响应运营。（业务中台的本质是为了更好地固化及沉淀企业的核心能力，并以中台集群的方式为核心竞争力的自我优化及进化提供充足的资源支撑）
2.数据中台建设目标导向-响应运营、响应业务、创造业务（数据中台有额外成本投入需目标导向：运营效率导向、客户经营导向、业务创新导向）
中台的目标就是，快速构建不同行业的产品。
中台思想，是依赖于微服务架构的。
（4）微服务架构的特点
微服务架构就是P2P模式，抛离了SOA的ESB，通过点对点的交互实现服务之间的调用。
微服务架构仅仅是一种架构风格，并没有引入新的技术。
将单个应用程序开发为一组小型服务的方法，每个服务都在自己的进程中运行，并使用轻量级（通常是Http、RPC、RMI）通信，可以通过完全自动化的部署机制进行独立部署，这些服务的集中管理是最低限度的，这些服务可以用不同的编程语言编写并使用不同的数据存储。
这些服务是围绕业务能力域构建的。
（5）微服务的主要特征
① 原子服务，专注一件事，功能单一，对其他功能的依赖少，减少服务网络关系，高内聚松耦合。② 高密度部署，重要服务可以独立部署，非核心服务可以独立打包，合到一个进程中，服务被高魔都部署。一台服务器可以部署多个服务实例进程。
（6）敏捷交付
服务由小研发团队负责设计、开发、测试、部署、线上治理、灰度发布和下限、运维整个生命周期支撑，实现真正的DevOps。
（7）微自治
服务足够小，功能单一，可以独立开发、打包、部署、升级、回滚和弹性伸缩。
不依赖其他服务（与不调用是两回事），实现局部自制。
（8）拆分方式
水平拆分：收编通用与公共服务，并形成独立而稳定的服务。
垂直拆分：划分成独立的业务或功能域，避免能力域之间的交叉性，而达到自治的特性。
（9）适应场景
业务变化频率高，需要快速试错，持续交互，缩短业务或产品发布周期。
需要高吞吐量的扩容伸缩架构（小颗粒服务更具弹性化，架构性能消耗/整体请求固执<=1%），平均响应时延增高。
最终一致性场景，来保证高的请求吞吐量，否则强一致性拉低整体服务吞吐量。
（10）目的
项目快速迭代
项目持续交付
降本提效
（11）架构图
也可以将公共逻辑抽离出来，单独抽为公共逻辑层。
（12）微服务框架演进
业务团队只专注于业务逻辑本身。
基础设施由基础研发团队负责。
基础设施能力从应用程序中下推。
一套基础设施支持多语言开发。
解耦业务团队与基础团队。
满足现今的快速迭代与快速试错、可持续性交付。
5、服务网格架构（Service Mesh）
服务网格是一种基础设施层，用于处理服务间的通信。
云原生应用有着复杂的服务拓扑，服务网格负责在这些拓扑中实现请求的可靠传递。
在实践中，服务网格通常时限为一组轻量级网络代理，他们与应用程序部署在一起，而对应用透明。
（1）服务网格架构的诞生
当应用A与应用B部署在不同的服务器上时，互相远程调用或许会因为网络问题而造成延时或丢失。
当基础服务与应用部署在同一个机器上时，通过本地回路网卡直接访问，大大减少网络延时。
6、无服务化架构（ServerLess）
Serverless 是云计算的一种模型。以平台即服务（PaaS）为基础，无服务器运算提供一个微型的架构，终端客户不需要部署、配置或管理服务器服务，代码运行所需要的服务器服务皆由云端平台来提供，以 Amazon Lambda 为典型服务 。根据CNCF的定义，Serverless是指构建和运行不需要服务器管理的应用程序的概念。Serverless 作为一种新型的互联网架构，推动云计算的发展。
写在后面
如果本文对你有帮助，请点赞收藏关注一下吧 ~
