面试官们“乐此不疲”分布式系统架构是什么鬼?

目录:

一、什么是分布式系统?

二、为什么要走分布式系统架构?

三、系统如何进行拆分?

四、分布式之后带来的技术挑战?

一、什么是分布式系统?

在谈分布式系统架构前,我们先来看看,什么是分布式系统?

假设原来我们有一个系统,代码量30多万行。现在拆分成20个小系统,每个小系统1万多行代码。

原本代码之间都是直接基于Spring框架走JVM内存调用,现在拆开来,将20个小系统部署在不同的机器上,然后基于分布式服务框架(比如dubbo)搞一个rpc调用,接口与接口之间通过网络通信来进行请求和响应。

所以分布式系统很重要的特点就是服务间要跨网络进行调用,我们来看下面的图:

此外,分布式系统可以大概可以分成两类。

(一)、底层的分布式系统

比如hadoop hdfs(分布式存储系统)、spark(分布式计算系统)、storm(分布式流式计算系统)、elasticsearch(分布式搜索系统)、kafka(分布式发布订阅消息系统)等。

(二)、分布式业务系统

分布式业务系统,把原来用java开发的一个大块系统,给拆分成多个子系统,多个子系统之间互相调用,形成一个大系统的整体。

举个例子,假设原来你做了一个OA系统,里面包含了权限模块、员工模块、请假模块、财务模块,一个工程,里面包含了一堆模块,模块与模块之间会互相去调用,1台机器部署。

现在如果你把他这个系统给拆开,权限系统,员工系统,请假系统,财务系统,4个系统,4个工程,分别在4台机器上部署。

然后一个请求过来,完成这个请求,员工系统去调用权限系统,调用请假系统,调用财务系统,4个系统分别完成了一部分的事情。

最后4个系统都干完了以后,才认为是这个请求已经完成了。这就是所谓的分布式业务系统。

同样,我们来一张图,感受一下上述过程:

二、为什么要走分布式系统架构?

有的同学可能要问了,我一台服务器跑的好好的,所有系统一个工程全部搞定,多好。为啥一定要去搞什么分布式系统架构,互相调用还要走远程,似乎还增加了不少工作量?

这里我就以我曾经待过的一个公司的血泪经历为例,来聊聊这个问题。

很多年前,在没有走分布式架构的时候,我待的这家公司的各个业务线都是垂直的 “ 烟囱式 ” 项目。

随着互联网的快速发展,公司的业务也在不断的发展,注册用户增加、网站应用的功能、规模不断扩大,特别是移动互联网的发展,APP、微信、自助终端机等访问渠道的增加,各种新业务,新需求不断涌入,系统遇到了各种各样的问题。

首先是项目工程无节制的变得臃肿庞大,系统复杂度增加,大几十万行代码,几十个开发人员,service层,dao层代码大量被copy使用,经常各种代码合并冲突问题要处理,非常耗费时间。

经常是我改动了我的代码,别人调用了我的接口,导致他的代码也出现问题,需要重新测试,麻烦的要死。

然后每次发布都是几十万行代码的系统一起发布,大家得一起提心吊胆准备上线,几十万行代码的上线,每次上线都要做很多的检查,很多异常问题的处理,每个人都高度紧张,被搞得几乎崩溃。

而且如果我现在有个新业务,打算把相关依赖升级一下,比如升级到最新的spring版本,还不行,因为这可能导致别人的代码报错,不敢随意乱改技术。并且一个web工程每次启动都需要好分钟的时间,本地IDE里面调试一次代码都很痛苦。

其次,随着用户访问流量的增加,系统负载压力变大,变得不堪重负,通过增加实例数,增加硬件扩容能够带来的效果已微乎其微,故障频发,效率低下。系统质量也越来越难以保证,测试周期也变得越来越长,无法满足公司业务发展的需要。

以上就是以前待过的公司一些 “不堪回首” 的往事,总得来说,问题主要体现在以下几个方面:

(一)、应用代码耦合严重,功能扩展难

(二)、新需求开发交互周期长,测试工作量大

(三)、新加入的开发同事需要很长时间才能熟悉系统

(四)、升级维护也很困难(改动任何一点地方都要升级整个系统)

(五)、系统性能提升艰难,可用性低,不稳定。

好,既然我们已经深刻体会到了系统耦合的痛苦,那么现在就来看看,系统拆分后带来的好处:

首先,系统拆分了以后,会感觉整个世界都清爽了。

几十万行代码的系统,假设拆分成20个服务,平均每个服务就1-3万行代码,每个服务部署到单独的机器上。20个工程,就用20个git仓库代码,20个开发人员,每个人维护自己的那个服务就可以了。

因为是自己独立的代码,跟别人没关系。再也没有代码冲突了,爽!
每次就测试我自己的代码就可以了,爽!
每次就发布我自己的一个小服务就可以了,爽!
技术上想怎么升级就怎么升级,保持接口定义不变,输入输出内容不变就可以了,爽!

总结起来一句话,分布式系统拆分之后,可以大幅度提升复杂系统大型团队的开发效率。

三、系统如何进行拆分?

一般来说,将系统进行拆分,首先需要对系统整体比较熟悉。可以走多轮拆分的思路,第一次拆分就是将以前的各个大的模块粗粒度的拆分开来。

比如一个电商系统可以拆分成订单系统、商品系统、店铺系统、会员系统、促销系统、支付系统等等。

后面可能每个系统又变得越来越复杂了,比如说订单系统又可以进一步拆分出来购物车系统,库存系统,价格系统等。

总得来说就是基于领域驱动设计的思想以及实战经验总结,同时参考业界一些常规做法,大家讨论着来进行拆分,逐步优化,多轮拆分,小步快跑,最终达到一个比较好的状态。

四、分布式之后带来的技术挑战?

首先就是分布式服务框架的选用,目前国内来讲主流的还是dubbo与spring cloud。

我们来思考一下,使用服务框架主要用来解决什么问题呢?如果不用dubbo或者spring cloud是否可以做分布式架构呢?

不用dubbo或者spring cloud等服务框架当然也是可以的,但是这就需要自己处理很多事情了。

比如,各个子系统走restful接口调用,那么就是http调用,这时比如传送过去一个对象,就要自己搞成一个JSON,然后一次调用失败后重试怎么做?

另外,一般来说都是集群部署,目标系统有多个实例,那么自己还要写一个负载均衡算法,如何每次随机从多个目标机器中挑选一个来调用?

还有,如果目标系统扩容新部署了一个实例,或者服务器故障下线了一个实例,如何动态让调用方感知到呢? 诸如此类的很多问题,如果不用服务框架的话,自己这么瞎搞,会遇到各种各样的问题。

上述过程,用一张图给大家呈现一下:

如果选用了某一个分布式服务框架,就需要深入的掌握这个框架的使用与底层原理,比如 dubbo 就需要搞明白以下的一些问题:

(一)、dubbo的工作原理?

(二)、dubbo支持的序列化协议?

(三)、dubbo的负载均衡和高可用策略?动态代理策略?

(四)、dubbo的SPI思想?

(五)、如何基于dubbo进行服务治理、服务降级、失败重试以及超时重试?

(六)、dubbo服务接口的幂等性如何设计(比如不能重复扣款,不能重复生成订单,不能重复创建卡号)?

(七)、dubbo服务接口请求的顺序性如何保证?

(八)、如何自己设计一个类似dubbo的rpc框架?

使用spring cloud也是一样,比如eureka的工作原理?feign声明式调用的原理?等等各种底层原理要搞懂。

还有其它一些走分布式架构后常见的要解决的技术问题:

(一)、分布式会话

(二)、分布式锁

(三)、分布式事务

(四)、分布式搜索

(五)、分布式缓存

(六)、分布式消息队列

(七)、统一配置中心

(八)、分布式存储,数据库分库分表

(九)、限流、熔断、降级等。

以上这些问题,往深了说,每一个点都需要可能 N 篇文章来详细阐述,这里没法逐一展开,后面我们会继续通过一些文章,聊一聊这些分布式架构下的各种技术问题。

原文地址:https://blog.51cto.com/14257001/2408391

时间: 2024-11-05 21:36:55

面试官们“乐此不疲”分布式系统架构是什么鬼?的相关文章

让面试官颤抖的Tomcat系统架构系列!

前言 俗话说,站在巨人的肩膀上看世界,一般学习的时候也是先总览一下整体,然后逐个部分个个击破,最后形成思路,了解具体细节,Tomcat的结构很复杂,但是 Tomcat 非常的模块化,找到了 Tomcat最核心的模块,问题才可以游刃而解,了解了Tomcat的整体架构对以后深入了解Tomcat来说至关重要! 一.Tomcat顶层架构 先上一张Tomcat的顶层结构图(图A),如下:Tomcat中最顶层的容器是Server,代表着整个服务器,从上图中可以看出,一个Server可以包含至少一个Servi

微软架构详谈,从面试官的角度谈面试:剑指Offer名企面试官精讲典型编程题

前言 我在微软做了很多年的面试官,后面七年多作为把关面试官也面试了很多应聘者.应聘者要想做好面试,确实应把面试当作一门技巧来学习,更重要的是要提高自身的能力.我遇到很多应试者可能自身能力也不差但因为不懂得怎样回答提问,不能很好发挥.也有很多校园来的应聘者也学过数据结构和算法分析,可是到处理具体问题时不能用学过的知识来有效地解决问题.这些朋友读读海涛的这本书,会很受益,在面试中的发挥也会有很大提高.这本书也可以作为很好的教学补充资料,让学生不只学到书本知识,也学到解决问题的能力. 主页 目录 第1

【真实面试经历】我和阿里面试官的一次“邂逅”(附问题详解)

本文的内容都是根据读者投稿的真实面试经历改编而来,首次尝试这种风格的文章,花了几天晚上才总算写完,希望对你有帮助. 本文主要涵盖下面的内容: 分布式商城系统:架构图讲解: 消息队列相关:削峰和解耦: Redis 相关:缓存穿透问题的解决: 一些基础问题: 网络相关:1.浏览器输入 URL 发生了什么? 2.TCP 和 UDP 区别? 3.TCP 如何保证传输可靠性? Java 基础:1. 既然有了字节流,为什么还要有字符流? 2.深拷贝 和 浅拷贝有啥区别呢? 下面是正文! 面试开始,坐在我前面

面试官对于消息队列的连环炮

1. 引子 消息队列分布式系统中重要的组件,一种存放消息的容器,主要作用有解耦.异步.削锋,是大型分布式系统不可缺少的中间件. 常见的消息队列有 ActiveMQ,RabbitMQ,RocketMQ,Kafka. 简历中涉及到了消息队列,面试官先问了这样几个问题: 你们系统里为什么要使用消息队列? 既然使用了消息队列,说说他还有什么使用场景? 消息队列的优缺点是什么? 2. 为什么使用消息队列? 我的回答:甲方提供 EOS 充值服务,我方进行调用.出于解耦的目的,引入了消息队列. 一个类似应试的

面试官的七种武器:Java篇

起源 自己经历过的面试也不少了,互联网的.外企的,都有.总结一下这些面试的经验,发现面试官问的问题其实不外乎几个大类,玩不出太多新鲜玩意的.细细想来,面试官拥有以下七种武器.恰似古龙先生笔下的武侠世界中的七种武器.下面我为各位一一道来. (欢迎转载.转载请注明出处:http://www.cnblogs.com/hzg1981/) 长生剑=语言基础 长生剑是七种武器之首,同理,编程语言的考察也是技术面试中最基本的.这条不满足的就直接Pass了.以Java为例,语言的考察大致可以分为三个层次: 初级

一个资深java面试官的“面试心得”

在公司当技术面试官几年间,从应届生到工作十几年的应聘者都遇到过.先表达一下我自己对面试的观点: 1.笔试.面试去评价一个人肯定是不够准确的,了解一个人最准确的方式就是“路遥知马力,日久见人心”.通过一.二个小时内的做题.交流,只是没有其他办法下进行的无奈之举,所以通过了面试不代表有多成功,没通过也不代表有多失败.2.好的面试官本身交谈的时候就不应当把自己一个居高临下的角色上,应当把自己和应聘者当做两个做技术的人平等的交流,把自己当作权威往往就会受到观点的角度.语言表达.工作领域的惯性的制约.3.

分布式系统架构的基本原则和实践(转)

采用分布式系统架构是由于业务需求决定的,若系统要求具备如下特性,便可考虑采用分布式架构来实现: 1.数据存储的分区容错,冗余 2.应用的大访问.高性能要求 3.应用的高可用要求,故障转移 分布式系统遵循几个基本原则 1.CAP原理 CAP Theorem,CAP原理中,有三个要素: 一致性(Consistency) 可用性(Availability) 分区容忍性(Partition tolerance) CAP原理指的是,在分布式系统中这三个要素最多只能同时实现两点,不可能三者兼顾.因此在进行分

Android开发面试经——5.常见面试官提问Android题(更新中...)

关注finddreams博客: http://blog.csdn.net/finddreams/article/details/44513579 一般的面试流程是笔试完就接着是面试了,面试时技术经理会问你一些你工作中遇到的Android方面的问题,谈谈你所做的项目,和在项目中所扮演的角色.今天我就给大家整理一些,面试中常见的面试官提的一些问题? 1.要做一个尽可能流畅的ListView,你平时在工作中如何进行优化的? ①Item布局,层级越少越好,使用hierarchyview工具查看优化. ②

Dubbo视频教程《基于Dubbo的分布式系统架构视频教程》----课程列表

Dubbo视频教程官网:http://www.roncoo.com/ 作者:吴水成,邮箱:[email protected] ,QQ:840765167 <基于Dubbo的分布式系统架构视频教程>包含基础篇.高级篇.高可用架构篇,教程以第三方支付项目的系统架构实战经验为背景,最终形成一套分布式系统架构解决方案.教程中涵盖的技术点包括 Dubbo分布式服务.ZooKeeper注册中心.Redis3.0分布式缓存集群.MySQL读写分离集群.FastDFS_v5.05分布式文件系统集群.Activ