文章探讨了计算机软件从客户端/服务器(c/s)时代到Web1.0和2.0的演变，重点介绍了互联网技术架构的逐步发展，包括分布式设计、ZooKeeper在分布式环境中的角色、Nginx的高并发处理、消息中间件如RabbitMQ和ActiveMQ的应用。文章还强调了高性能架构的学习路线和集群与分布式的区别。
首先我们了解下计算机软件的发展历史,大概总结概括，分为c/s时代，web1.0时代和web2.0时代。
**c/s时代:**富客户端方案。卖软件可赚钱。例如 qq、影音、游戏。
**1.0时代:**主要是单向信息的发布，即信息门户—广大浏览器客户端 ，互联网内容是由少数编辑人员（或站长）定制的。
表是三大门户，新浪/网易/搜狐。新浪以新闻+广告为主，网易拓展游戏为主，搜狐延伸门户矩阵
**2.0时代:**注重用户的交互。每个人都是内容的供稿者。 RSS订阅扮演一个很重要的作用。
例如:博客、播客、维基、P2P下载、社区、分享服务
时至今日，互联网的形式演变已经变成全员参与，老少皆宜的活动。因此，互联网相关的技术也是要求越来越高，参与人数的增加也让系统的负担越来越大。
三、技术架构演进史
以下为2017年天猫双11的交易指标。那么大的数据量,那么快的处理请求，显然单台机器，单个服务绝对是无法支撑的。
那么怎么办呢，我们将原本单台部署，单台处理的服务，需要进行拆分以及部署到不同的服务器中去，使其用多台机器去处理，分担压力。但是我们又要保证系统的完整性。这就是分布式的设计。接下来我们看下服务架构的演进史。
架构演进一: 早期雏形
特征：应用程序主要做静态文件读取，返回内容给浏览器。
**架构演进二: **数据库开发（LAMP特长）
特征：应用程序主要主要读取数据表值，填充html模块。业务逻辑简单，写sql
架构演进三: javaweb的雏形
特征：tomcat + servlet + jsp + mysql。一个war包打天下
项目结构：ssh/ssm三层结构。
架构演进四: javaweb的集群发展
特征：硬件机器的横向复制，对整个项目结构无影响。
架构演进五: javaweb的分布式发展
特征：将Service层单独分离出去，成为一个单独的项目jar。单独运行。Web服务器通过rpc框架，对分离出去的service进行调用。
架构演进六: javaweb的微服务发展
特征：从业务角度，细分业务为微服务，每一个微服务是一个完整的服务（从http请求到返回）。在微服务内部，将需要对外提供的接口，包装成rpc接口，对外部开放。
集群与分布式的区别
我在面试的时候，发现很多同学会把集群和分布式混淆，其实他俩完全是两个东西
分布式：纵向拆分，一个业务分拆多个子业务，部署在不同的服务器上。主要是业务层面拆分，进行业务解耦，从而提高服务高可用以及高性能。
集群：横向复制，同一个业务，部署在多个服务器上，前面通过负载均衡，起到分担压力的作用。而且这些服务器中，即使有一两个宕机也不会影响到整体业务。
本章主要讲了一下高性能架构的学习路线，以及技术演进史。接下来聊聊Alibaba百万年薪架构师必备技能——高性能架构学习路线（笔记）：中间件、Nginx、缓存、ZK等等…看下方高性能架构进阶技能图…
说明：以下全部所说的架构师必备技能之高性能架构学习路线及相关笔记：中间件、Nginx、缓存、ZK等等等，篇幅有限，很多都是截图展示，但是图片都是很高清的，可以清晰的看见其中的内容。而且完整的原件pdf+xmind文件，小编这里也都收整好了**“点击这里下载”**
一、Zookeeper分布式环境指挥官
1.1 zookeeper基础
ZooKeeper是一种分布式协调服务，用于管理大型主机。在分布式环境中协调和管理服务是一个复杂的过程。ZooKeeper通过其简单的架构和API解决了这个问题。ZooKeeper允许开发人员专注于核心应用程序逻辑，而不必担心应用程序的分布式特性。
1.2 分布式应用的优点
-
（1）可靠性 - 单个或几个系统的故障不会使整个系统出现故障。
-
（2）可扩展性 - 可以在需要时增加性能，通过添加更多机器，在应用程序配置中进行微小的更改，而不会有停机时间。
-
（3）透明性 - 隐藏系统的复杂性，并将其显示为单个实体/应用程序。
1.3 分布式应用的挑战
-
（1）竞争条件 - 两个或多个机器尝试执行特定任务，实际上只需在任意给定时间由单个机器完成。例如，共享资源只能在任意给定时间由单个机器修改。
-
（2）死锁 - 两个或多个操作等待彼此无限期完成。
-
（3）不一致 - 数据的部分失败。
1.4 Zookeeper相关笔记
- ZK 手写笔记（1）：概述+CPA+环境搭配+一致性协议+基本使用
- ZK 手写笔记（2）：源码解析+应用场景
二、Nginx高并发分流进阶实战
2.1 nginx如何实现高并发
-
简单来讲，就是异步，非阻塞，使用了epoll和大量的底层代码优化。
-
稍微详细一点展开的话，就是nginx的特殊进程模型和事件模型的设计。
2.2 进程模型
-
nginx采用一个master进程，多个woker进程的模式。
-
master进程主要负责收集、分发请求。当一个请求过来时，master拉起一个worker进程负责处理这个请求。
-
master进程也要负责监控woker的状态，保证高可靠性
-
woker进程一般设置为跟cpu核心数一致。nginx的woker进程跟apache不一样。apche的进程在同一时间只能处理一个请求，所以它会开很多个进程，几百甚至几千个。而nginx的woker进程在同一时间可以处理额请求数只受内存限制，因此可以处理多个请求。
2.3 事件模型
nginx是异步非阻塞的。
每进来一个request，会有一个worker进程去处理。但不是全程的处理，处理到什么程度呢？处理到可能发生阻塞的地方，比如向上游（后端）服务器转发request，并等待请求返回。那么，这个处理的worker不会这么傻等着，他会在发送完请求后，注册一个事件：“如果upstream返回了，告诉我一声，我再接着干”。于是他就休息去了。此时，如果再有request 进来，他就可以很快再按这种方式处理。而一旦上游服务器返回了，就会触发这个事件，worker才会来接手，这个request才会接着往下走。
web server的工作性质决定了每个request的大部份生命都是在网络传输中，实际上花费在server机器上的时间片不多。这是几个进程就解决高并发的秘密所在。
2.4 Nginx相关笔记
- Nginx 常见应用技术指南[Nginx Tips]
- 深入剖析Nginx
三、rabbitMQ消息中间件
-
（1）Broker：消息中间件实例, 可能是单个节点也可能是运行在多节点集群上的逻辑实体
-
（2）消息(Message)：消息由消息头和消息体两部分组成。消息头中包括routing-key、priority等标准消息头以及其它自定义消息头，用于定义RabbitMQ对消息行为。消息体是字节流，包含消息内容。
-
（3）连接(Connection)：客户端与 Broker 之间的 TCP连接
-
（4）信道(Channel) ：Channel 是建立在 TCP 连接上的逻辑(虚拟)连接。多个 Channel 复用同一个 TCP 连接, 以避免建立 TCP 连接的巨大开销。 RabbitMQ 官方要求每个线程使用独立的 Channel, 禁止多个线程共用 Channel。
-
（5）生产者(Publisher)：发送消息的客户端线程
-
（6）消费者(Consumer)：处理消息的客户端线程
-
（7）交换机(Exchange)：交换机负责将消息投递到相应的队列
-
（8）队列(Queue)：接收并保存交换机投递的消息，直至被消费者成功消费。逻辑结构遵循先进先出FIFO。
-
（9）绑定(Binding)：将队列(Queue)注册到交换机(Exchange)的路由表
-
（10）虚拟主机(Vhost)：每个Broker下可建立多个vhost, 每个 vhost 可建立独立的 Exchange、Queue、绑定及权限系统。同一个 Broker 下的 vhost 共享 Connection、Channel 和 用户系统，就是说可以使用同一个用户身份使用同一个 Channel 访问不同 vhost。
3.1 rabbitMQ消息中间件相关笔记
- RabbitMQ-最完整最全教程
- RabbitMQ实战指南
四、ActiveMQ消息中间件
- （1）多种语言和协议编写客户端。语言: Java,C,C++,C#,Ruby,Perl,Python,PHP。应用协议: OpenWire,Stomp REST,WS Notification,XMPP,AMQP
最后
如果觉得本文对你有帮助的话，不妨给我点个赞，关注一下吧！
#,Ruby,Perl,Python,PHP。应用协议: OpenWire,Stomp REST,WS Notification,XMPP,AMQP
最后
如果觉得本文对你有帮助的话，不妨给我点个赞，关注一下吧！
[外链图片转存中…(img-zuRskyaR-1714813654385)]
[外链图片转存中…(img-olAGfzOq-1714813654385)]
312
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
