大型互联网项目架构目标
传统项目与互联网项目
传统项目：某公司oa系统，hr系统，打卡系统
互联网项目：天猫，百度，jd
| 传统项目 | 互联网项目 | |
|---|---|---|
| 使用群体 | 企业员工 | 全体网民 |
| 并发量 | 1-几千 | 百万-亿 |
| 产品忍耐度 | 忍耐度高 | 几乎零忍耐 |
| 安全性 | 安全性高 | 易受攻击 |
| 功能 | 功能简单 | 功能复杂 |
| 更新 | 更新慢 | 更新快 |
从对比图可看出互联网项目要做到：
高并发，响应速度快，稳定性好，用户体验好
衡量网站性能指标
响应时间:指执行一个请求从开始到最后收到响应数据所花费的总体时间。
并发数:指系统同时能处理的请求数量。
-
并发连接数:指的是客户端向服务器发起请求，并建立了TCP连接。每秒钟服务器连接的总TCP数量
-
请求数:也称为QPS(Query Per Second)指每秒多少请求
-
并发用户数:单位时间内有多少用户
吞吐量:指单位时间内系统能处理的请求数量。
高性能:提供快速的访问体验。
高可用:网站服务一直可以正常访问。
可伸缩:通过硬件增加/减少，提高/降低处理能力。
高可扩展:系统间耦合低，方便的通过新增/移除方式，增加/减少新的功能/模块。
安全性:提供网站安全访问和数据加密，安全存储等策略。
集群和分布式
大型互联网项目都需要用到的技术：集群和分布式
集群
很多“人”一起，干一样的事，比如一个餐馆做菜需要切菜的，做菜的，洗碗的，上菜的；原本一个厨师负责全部的工作，后来又招了新厨师，新厨师也是干所有的工作也分担了原厨师的压力，新厨师和原厨师就是集群
分布式
很多“人”一起，干不一样的事。这些不一样的事，合起来是一件大事。原本的厨师不再负责切菜，洗碗，上菜，而是招了三个人分别负责，这样每个人只用专心干一件事，效率会很高
集群+分布式（可伸缩）
如果餐馆有许多订单，那么我们可以招聘两个厨师团队，将订单分成两份，两个厨师团队之间就相当于集群，每个团队内部则是通过分布式的方式做菜，这种添加团队的方式实现了可伸缩性
架构发展历史
单体架构
将一个程序所有的模块放到一个服务器里，可以由多态服务器构成集群实现多机单体架构
优点： 开发部署方便，适合小型项目
缺点：
- 项目启动慢
- 可靠性差：某个模块坏了整个项目都坏了
- 可伸缩性差
- 扩展性差
- 低性能
垂直架构
垂直架构是指将单体架构中的多个模块拆分为多个独立的项目。形成多个独立的单体架构。
相较于单体架构基本都有了优化，但是垂直架构也有自己的缺点：
每个app之间并不交互，例如登录页面，个人信息页面这种每个模块都需要的功能需要每个app都进行添加，导致重复功能变多
分布式架构
在垂直架构的基础上将重复的模块抽离出来形成一个独立的模块成为服务提供者
RPC：消费者调用服务提供者的方式
分布式架构的缺点：
服务提供方一旦发生变更，囊额所有消费方都需要变更
SOA架构
消费者和提供者并不直接通信，而是通过服务总线实现两者的交互
ESB: 企业服务总线，服务中介。主要是提供了一个服务于服务之间的交互。ESB包含的功能如∶负载均衡，流量控制，加密处理，服务的监控，异常处理，监控告急等等。
微服务架构
微服务架构是在SOA上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。
Dubbo是SOA时代的产物，SpringCloud是微服务时代的产物
下一篇：(27条消息) 从零开始学习Dubbo2——什么是Dubbo和zookeeper的安装_崔泡泡—猫的博客-CSDN博客