系统部署架构图怎么画（系统部署架构图教程）
-
-
类目：知识大全
-
联系人：
-
微信号：
-
Q Q 号：
-
手机号：
-
浏览量：
322
【商户信息】
【货源详情】
泪目，不堪回首！
博主毕业4年了，最近开始了秋季的招募。 每当想起自己秋天的招生，就感到当时自己的特别遗憾。 “做饭是原罪”。 自己简历上面的项目，只有一个农资电商平台，当时的秒杀系统还不那么普及。
第一次微众面试
当时自己的八股文其实还可以，自己的项目只是单机系统，分散吗？ 微服务？ 是什么？ 我还记得当时的微信面试。 是两面。 在酒店的房间里，面试官笑嘻嘻地看着我，说请画出我项目中的农资电商平台。 我的头在嗡嗡叫。 是什么？ 怎么画，是安卓系统、首页、后台系统吗？
差不多是这样的
我擦，这太简单了吧。 我应该画得再复杂一点吗？ 还是我可以把这个称为体系结构？ 这样，犹豫间，毛线没有画出来…我记得当时就像画了这样的东西一样。 并不意外。 我打嗝了~
这有点不像，别说了，丢脸~
第二次微众面试
第二次微众面试，毕业快一年了。 抱着试试看的心情，找了老师和姐姐介绍。 那时我在做什么？ 我曾做过爬虫类。 公司离得有点近，就在金蝶那里。 下班后溜之大吉，和面试官发了一会儿脾气。 是个好家伙。 过了一会儿，我拿出一张纸。
画出你们现在这个爬虫系统的结构图吧！
当时的系统部署架构很长吧。 看起来比上面的东西简单一点。
但是，我不会画画。 在心里想很容易啊。 这能称为体系结构吗？
摊牌了， 我不会画！
现在想起来，真的很憋气。 真年轻啊。 那么，现在回想起来，怎么画呢？
单体系统的部署体系结构图
爬行动物系统的分层结构图
爬行动物系统的业务体系结构
架构图
从上述各个方向说明体系结构，实际上即使是单个系统也能画出不常见的体系结构图！ 为什么那时我做不到！ ）
最近看了架构相关的内容(华仔的课)，在4.1视图中，从多个方面对我们的系统进行了说明。 请参考以下说明。
你的秒杀系统，架构是怎么样的？
单体系统
不管你们的简历怎么硬吹，我想你们的服务，大部分都是这样的。 如果击中，请关注。 只有浏览器是分散的。
那我该如何去描述我的单体系统呢？
体系结构设计的三个原则：
简单的原则
恰当的原则
进化原则
所有的原则都符合我们大学制定的秒杀系统啊。
简单原则：一个系统就能满足我们秒杀服务的所有行为，没有太多中间件依赖
合适的原则：在我们的实践项目中，单体系统是最佳的。 主要是没钱啊。 分割服务、部署中间件、部署集群都需要花钱啊。 ）
进化原则：这个比较容易理解，没有一出生就决定的系统架构，是随着时间、业务需求而进化的。
总结：
我们体系结构的优点：成本低，系统复杂性低，维护成本低，能够快速识别问题
缺点：稳定性差、并发量低、可扩展性弱等
整理架构时，每种方案都有利弊，所以需要了解你现在方案的优缺点。 可以更好地向面试官展示你的系统！
服务拆分
好家伙，参加科技竞赛，资金到位了，可以买更多的机器了。 那就优化服务，不要拆分微服务系统出去！
在这个服务分割的框架中，我们做了什么样的动作？
静态资源隔离(CDN加速)
代理服务器(Nginx )
分割服务，应用独立部署
服务rpc通信(rpc框架注册中心)
1、前后端分离
在单元系统中，我们的静态资源(Html、JS、CSS、IMG )都有可能从我们的服务器端返回。 问题如下。
前端代码的维护成本相对较高(完整堆栈开发成本也较高) )。
需要公开前端代码，公开整个系统
服务器带宽、请求资源的消耗量等
那么，前后端分离的好处很明显：
导线独立维护(低耦合)，释放成本低(高效率)
前后端通过接口交换动态数据
加快了对CDN资源的访问速度，减轻了后端服务器负载(高性能) ) ) ) ) ) ) ) ) ) )
2、反向代理
反向代理的作用很明显，因为我们的服务被分割为多个，所以在与前端对话时需要提供共同的入口。 这个入口是我们的反向代理服务器(Nginx )。 例如，根据服务域名： https://www.jiuling.com、rest风格规范，在https://www.jiuling.com/user/1.0/log in中是用户服务的登录界面
3.进程间通信
随着服务的分割，一些功能的实现涉及到服务之间的相互调用。 例如：
典型的实现方案使用注册中心和RPC框架来实现此功能。 我们经常使用的实现方案是zookeeper dubbo。
为什么要使用RPC框架？
当谈到使用RPC框架时，您考虑过为什么使用RPC框架吗？ 不是也可以为每个服务提供rest风格的接口，进行服务间通信吗？
这里需要比较RPC和rest风格的差异：
消息大小小，传输效率快： RPC简化了传输协议所需的报头信息，提高了传输效率。
开发成本较低：例如，Dubbo框架应该封装服务间呼叫的逻辑，并开发合适的接口和数据模型，例如反射、链路的建立和超时控制。
在分布式方案中，如果有多个服务提供者，则服务治理器：需要应对服务健康、负载均衡、服务流控制等情况。 这一能力的一部分在rpc注册中心的框架下得到满足。
好处结束后，让我们分析一下RPC的坏处：
强耦合性：与rest风格相比，RPC框架更难在跨语言场景中实现。 而且版本依赖性很强。 服务脱离当前内部网环境后，无法正常提供服务，迁移成本高。
内部网呼叫： RPC适用于内部网传输，在公共网络环境中似乎不太安全。
分布式微服务
以前版本的服务划分根据业务边界、功能和责任划分了多个子系统，但每个系统的负载都不一样。 例如，我花了很长时间处理订单服务器上的每个请求，而处理其他服务器没花多少时间。 为了增加订单量，只需扩展订单服务即可。 这就是服务分割带来的收益、性能的提高。
从上图中可以看到，一些服务器产生了不同的重影。 每个框可以理解为一台机器。 该体系结构主要将服务器集中在订单服务上，以保证订单成功率和订单量。
在此之前，让我们看一下中间件集群的部署。
mysql主从结构：读写隔离，减轻主库压力，确保数据正常写入，保障订单数据掉库。
zookeeper主从架构：保证注册中心的使用，防止整个链接雪崩。
redis哨兵群集：防止redis宕机导致大流量直接命中数据库。
小结
到目前为止，一般我们独自开发的系统，几乎完成了整个秒杀系统的进化。 大家可能一直有疑问，为什么我们最熟悉的MQ减少了呢？
在整个呼叫链接中，我通过同时呼叫来说这个秒杀系统的结构。 这已经满足了我们现在的流量诉求，所以在结构设计的原则中，提到了合适的原则，发展的原则。 在目前满足流量需求的情况下，部署消息中间件会出现什么问题？ 解决的问题是什么？ 是时候比较讨论一下利害关系，然后由我们决定是否使用这个方案了。
高性能
在上述体系结构的演进过程中，我们通过服务划分、垂直扩展、分布式部署等方式提高了我们体系结构的性能和稳定性。 虽然对于我们自身研究阶段的架构演进已经足够满足我们的流量诉求，但如果想继续优化我们的系统，提高服务性能，可以从以下几个方面进行优化。
资源预热
缓存预热
异步调用
1、资源预热
在上面的服务划分阶段，我们讨论了包括html、js、css和img等静态资源在内的资源动态隔离。 在我们的活动阶段，可以通过后台管理系统将商品服务器中活动的静态资源预热为CDN，加快资源访问。
资源预热：通过提前将资源加载到CDN中
回源：如果没有找到资源，CDN就触发源站(商品、服务)的调用，查询相应的资源，如果源站有资源，则返回CDN进行缓存。
OSS )实际存储静态资源的服务(可参见阿里巴巴云OSS ) ) ) ) ) ) ) ) ) ) )。
如上所述，部署一种技术时，必须同时考虑其带来的利与弊，那么CDN的风险是什么呢？
成本：比较直接，很花钱！
带宽： CDN能否支持高流量访问所需的带宽。 每台服务器能够支持的通信量是有限的，必须考虑CDN是否能够支持业务访问量。
CDN命中率3360如果CDN命中率较低，例如活动图像每小时更改一次，则每次更换图像时都会触发返回源的操作，反而会降低资源访问效率。
2、缓存预热
与上述静态资源加速相比，动态数据需要通过缓存优化性能。 为什么redis那么快呢？
单线程(这不是一个优势，因为这里没有redis的性能瓶颈)。
复用I/O复用模型
数据结构简单
基于内存的操作
引入redis带来的风险主要是：
reids down :如果是独立部署，大量的服务呼叫会超时，最终导致服务雪崩。 可以通过Sentinel集群进行优化。
高速缓存中断：对于大流量，请求会透明到数据库，例如在高速缓存MISS或高速缓存过期时。 如果数据库承担不了压力，就会引起服务雪崩。 可以用布隆过滤器优化。
数据完整性：缓存数据和数据库数据的完整性问题必须通过更新策略加以保障。
3、异步调用
通过异步方式，将成功削减库存的用户，通过消息方式发送到订单服务器，进行之后的订单操作。 可以在短时间内销售所有的商品。 整体流程如下图所示。
MQ异步调用为什么能提高我们的服务吞吐量？
其主要原因是通过异步调用传递消息来完成此次请求处理。 那么，性能瓶颈从订单服务器转移到了秒杀服务器上。 通过减少调用依赖，提高了整个服务的吞吐量。
MQ带来的常见问题：
数据完整性
重复消费：生产者重复投递信息，或因消费缓慢而重复推送信息。 需要通过摇号、消费幂等来保证消费正常。
信息堆积：当生产能力远大于消费能力时，会导致信息堆积。
MQ可用性： MQ停机时，需要支持并发呼叫切换。
这里不详细介绍，之后先写MQ相关的文章。
高可用
看这里很辛苦。 感谢大家的支持。 关于可用性，以前写过# 《高可用实战》 -B站飞出的，我的a站发生了什么吗？ 如果你感兴趣的话可以看看。
高可用性主要来自以下内容
动态扩展：根据服务压力动态扩展各种服务。
限流熔断：请参考我前面的文章。 # 《高可用实战》 -B站冲出去了。 我的A站有什么？
通过在异地部署：到多个机房，可以避免物理攻击！
同城双活
布置在同一城市不同地区的机房，通过专用网络连接。 两个机房的距离一般为几十公里，网络传输速度与机房差不多，降低了系统的复杂度和成本。
该模型无法解决一个城市的地震和水灾等极端灾情。 它用于解决机房火灾、停电、空调故障等常规故障。
异地多活
上述模型无法解决水灾、地震等城市级服务灾害。 可以通过多种异地部署方案解决此问题。
但每种方案都有其优缺点，异地多活的弊端主要体现在网络传输和数据一致性问题上！
城市之间的主要问题是网络传输延迟，例如从北京到广州，通常的RTT(round-triptime往返延迟)是50毫秒。
如果遇到网络变动等，会从500毫秒上升到1秒，有丢包的问题。
物理距离必然会导致数据不一致，必须从“数据”的特性来解决。
如果是存款余额等要求很强一致性的数据，就不能进行场外的很多工作。
