搭载Dubbo+Zookeeper踩了这么多坑,我终于决定写下这篇!

大型互联网项目架构目标

衡量网站的性能指标：

•响应时间：指执行一个请求从开始到最后收到响应数据所花费的总体时间。
•并发数：指系统同时能处理的请求数量。
•并发连接数：指的是客户端向服务器发起请求，并建立了TCP连接。每秒钟服务器连接的总TCP数量
•请求数：也称为QPS(Query Per Second) 指每秒多少请求.
•并发用户数：单位时间内有多少用户
•吞吐量：指单位时间内系统能处理的请求数量。
•QPS：Query Per Second 每秒查询数。
•TPS：Transactions Per Second 每秒事务数。
•一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
•一个页面的一次访问，只会形成一个TPS；但一次页面请求，可能产生多次对服务器的请求，就会有多个QPS

集群和分布式

传统

• 集群: 很多人干同一件事情

很多台服务器,上边负责同一个模块

• 分布式 : 很多人干不同的事情,合起来是一件大事情

很多台服务器,上边负责不同的小模块,最后合成一个大模块

​

• 集群和分布式,往往是同时存在的

高可用性

• 一个服务器挂了,不会影响另一个服务器,可以保证服务一直处于可用状态

高伸缩性

• 由于把各个模块尽量抽离开了,降低了彼此之前的耦合关系,所以比如要给E模块加多几个,可用直接加不会影响其他模块

高可扩展性

• 类似开闭原则,因为耦合度不高,所以扩展起来不是很难

架构演变

假设项目由 ABCD基础模块组成 E是公共模块

单体架构

• 一个服务器上,放着一整个项目 ABCDE

垂直架构

• 把项目拆成独立(互相没有关联)的两个模块 如 AB CD , 此时的E呢,因为两个服务器没有关联,所以E就不得不部署多次.即 ABE CDE 两台服务器

缺点

• 公共模块在每个服务器上都需要用到

分布式架构

• 垂直架构看起来已经是 不同服务器干不同的事情了, 不过还有一个公共模块E,在两个服务器中都出现过,我们要优化的话,可以多加一台服务器,单独放E

远程调用E(RPC)

• 用到 HTTP REST风格等(Dubbo都帮我们封装好了)

缺点

• E一但发生了改变,所有调用他的地方都需要去改变