cvmachine.com - 申博开户网

搜索: 您的位置主页 > 网络频道 > 阅读资讯:从0开始学架构课后题

从0开始学架构课后题

2019-04-12 08:38:30 来源:www.cvmachine.com 【
01. 你原来理解的架构是如何定义的?对比我今天讲的架构定义,你觉得差异在哪里?

一直以来,对架构这个词不知道怎么表述,似乎就是指一些MVC,前后分离,读写分离等等这些概念的集成,这些似乎也没错,但是不够准确。李的定义是 ”软件架构指软件系统的顶层架构“ ,详细讲就是1. 系统是一群关联个体的组成。2. 个体需要按照某种规则运行,架构需要明确个体运行和协作规则。
我原来的架构定义属于比较含糊,把不同层级的东西放在一块,结果怎么也讲述不清,每个层级有每个层级的架构。李的定义则抽象和清晰。

02.为何结构化编程、面向对象编程、软件工程、架构设计最后都没有成为软件领域的银弹?

所谓银弹是指能大规模提高软件工程生产力的技术或方法。因为软件的复杂度是越来越高,原先为解决这些复杂度的方法终究会失效,这些方法的主要思想就是模块化,组件化,只不过是粒度越来越粗,但软件开发本身具有复杂性,不可见性和可变性,这些技术都不能根本的解决这些问题。

03. 请按照“架构设计的主要目的是为了解决软件复杂度带来的问题”这个指导思想来分析一下你目前的业务系统架构,看看是否和你当时分析的结果一样?

以在线广告投放为例
性能:平日流量总计在100亿左右,高峰期如双十一等则流量会翻好几倍。 平日平均12w qps/s, 按照峰值是均值的3倍,则峰值流量在36w qps/s, 而双十一又是这个数量的数倍,并且,adx对延迟容忍度非常低,要求响应在100ms以内,性能要求非常高,好消息是1. adx与rtb之间的连接是长连接,2. 来的流量有一部分不是我们想要的量,可以通过简单规则过滤。
可扩展性:因为成本问题,在高峰时需要简单扩容机器就可以承受压力。
高可用:短暂的停机重启(<15 分钟)可以忍受, 时间长了当天的投放任务可能完不成。
安全性:涉及隐私的个人信息很少。
成本:1.量很大,单机性能要高,2. 高峰低谷差距很大,要尽可能合理安排机器。

系统的复杂度体现在性能和扩展性方面,尤其是性能。

04. 你所在的业务体系中,高性能的系统采用的是哪种方式?目前是否有改进和提升的空间?

我所在业务(RTB)两种方式都有采取,单机:内存计算,基本不涉及磁盘,redis,httpcomponents reactor,多线程,线程池,异步,消息队列,调用子系统少(只有fc)。集群:F5负载均衡到多台机器

05.高性能和高可用是很多系统的核心复杂度,你认为哪个会更复杂一些?理由是什么?

高可用更复杂,高性能通过拆分优化+堆机器都能比较好的解决,而高可用则是机器越多越复杂,环境因素更大,不可控因素更多。

06.你在具体代码中使用过哪些可扩展的技术?最终的效果如何?

接口,虚类,设计模式等等。对于可预测的变化和差异较小的变化可以解决,要多写不少代码,对于大的变化无解。

07. 学习了6大复杂度来源后,结合你所在的业务,分析一下主要的复杂度是这其中的哪些部分?是否还有其他复杂度原因?

我所在业务复杂度主要来源是高性能和规模。高达几十万的qps/s是问题的主要来源,还有就是积累的数据量(用户信息,网页信息)越来越大是离线处理和在线分析的复杂度来源。

08.我讲的这三条架构设计原则是否每次都要全部遵循?是否有优先级?谈谈你的理解,并说说为什么。

架构设计的三原则,分别是合适优于业界领先、简单优于复杂、演化优于一步到位。
应该是合适优于业界领先> 简单优于复杂>演化优于一步到位。选择架构,最重要的是基于业务,所以合适是最重要的,如果业务复杂或要求高,简单的架构不能承载业务就必须选复杂的架构,演化优于一步到位说的也是适合业务优先,而不是追求一步到位。

09.搜索一个互联网大厂(BATJ、TMD等)的架构发展案例,分析一下其发展过程,看看哪些地方体现了这三条架构设计原则。

以美团的技术架构为例
初期:从0开始学架构课后题
简单优于复杂,业务刚开展,只要能完成业务就行
业务继续发展:从0开始学架构课后题
演化优于一步到位,根据业务发展来优化

2011年加入移动端:
从0开始学架构课后题
合适优于业界领先
目前的架构:
从0开始学架构课后题
演化优于一步到位

10.尝试用排查法分析一下你参与过或者研究过的系统的复杂度,然后与你以前的理解对比一下,看看是否有什么新发现?

见问题3,复杂性体现在高性能流量处理,高可扩展性。

11. 除了这三个备选方案,如果让你来设计第四个备选方案,你的方案是什么?

消息队列的复杂性主要体现在这几个方面:高性能消息读娶高可用消息写入、高可用消息存储、高可用消息读龋设计TPS为1380,QPS为13800
消息队列一般具有时间特性,把近期的数据缓存在redis中提高读性能,单个redis进程读都能达到3w qps/s,为保证数据安全,在写redis之前将数据写入mysql。另,单一redis list不能支撑1380的写入,可以将同一消息队列中消息分散写入多个list。

12.RocketMQ和Kafka有什么区别,阿里为何选择了自己开发RocketMQ?
Rocketmq相比于Rabbitmq、kafka具有主要优势特性有:
o    支持事务型消息(消息发送和DB操作保持两方的最终一致性,rabbitmq和kafka不支持)
o    支持结合rocketmq的多个系统之间数据最终一致性(多方事务,二方事务是前提)
o    支持18个级别的延迟消息(rabbitmq和kafka不支持)
o    支持指定次数和时间间隔的失败消息重发(kafka不支持,rabbitmq需要手动确认)
o    支持consumer端tag过滤,减少不必要的网络传输(rabbitmq和kafka不支持)
o    支持重复消费(rabbitmq不支持,kafka支持)

由此可见,RocketMQ主要特性是支持事务性消息,在某些需要强一致性的业务中(如支付等),跨系统的事务性有非常强烈的需求,所以阿里需要开发RocketMQ。

13.你见过“PPT架构师”么?他们一般都具备什么特点?

只懂概念,不懂实现
实际上很普通的技术一定要安上一个高大上的名词
追求“高大全”,集群,高可用,分布式满天飞
具有销售的潜力,选择了错误的职业

14.数据库读写分离一般应用于什么场景?能支撑多大的业务规模?

读写分离一般应用于读多写少的地方,如新闻,论坛等等,业务的规模瓶颈一般在于写的性能方面,因为读不够了可以再添加slave,甚至缓存,写的瓶颈单机一般在单机1000/s到5000/s,另外假如单表数据量太多(>1000w)或太大(100G),即使有索引,读性能也开始下降。

15. 你认为什么时候引入分库分表是合适的?是数据库性能不够的时候就开始分库分表么?

并不是性能不够就开始分库分表,而是单表数据太多或太大的时候开始考虑分库分表。性能不够的原因有很多,只有找不到其他方法优化性能的时候才考虑分库分表,因为分库分表引入的复杂度是很大的。

16.因为NoSQL的方案功能都很强大,有人认为NoSQL = No SQL,架构设计的时候无需再使用关系数据库,对此你怎么看?

在肯定场合特别是互联网企业的业务中,NoSQL有很大的发挥余地,但是在要求事务性,稳定性的业务中,关系数据库仍然必不可少。

17.分享一下你所在的业务发生过哪些因为缓存导致的线上问题?采取了什么样的解决方案?效果如何?

没遇见过。

18.什么样的系统比较适合本期所讲的高性能模式?原因是什么?

连接不会太多,业务处理比较复杂,容易出错的系统(比如很多企业服务)适合本期的高性能模式。企业服务用户数量有限,但是稳定性要求高,单个用户异常可以接受,但是不允许单个用户异常影响到其他用户的使用。

19.针对“前浪微博”消息队列架构的案例,你觉得采用何种并发模式是比较合适的,为什么?

多Reactor多进程/线程

  1. “前浪微博”消息队列架构是基于linux,linux上AIO不完善,所以不选Proactor
  2. 消息队列要求读写消息性能非常高,实际用于处理消息的时间不多,所以多Reactor才能有更高的并发。
20. 假设你来设计一个日活跃用户1000万的论坛的负载均衡集群,你的方案是什么?设计理由是什么?

日活跃1000w用户,则用户数肯定上亿了,论坛的业务复杂度不高,分库分表可以满足要求。假设每天每个用户查看100个页面,平均流量就是1000w*100/86400=1.15w qps/s,考虑峰值和负载余量,1.15 * 3 * 3=10w/s,考虑成本因素,由一台LVS在最前端做负载均衡,转发到多个集群上,每个集群使用nginx转发到具体机器上。

21.微信抢红包的高并发架构,应该采取什么样的负载均衡算法?谈谈你的分析和理解。

微信抢红包功能包括发红包,抢红包两个主要功能,发红包可以根据地理位置,响应时间等路由到某台服务器上去,但生成的id可以指示路由到该服务器,抢红包根据该id操作。所以抢红包的负载均衡算法是hash类的。

22.基于Paxos算法构建的分布式系统,属于CAP架构中的哪一种?谈谈你的分析和理解。

paxos算法大体是第一次由提交者Leader向所有其他服务器发出prepare消息请求准备,所有服务器中大多数如果回复诺言承诺就表示准备好了,可以接受写入;第二次提交者向所有服务器发出正式建议propose,所有服务器中大多数如果回复已经接收就表示成功了。
paxos在某些节点失效时仍能工作,所以其是AP架构,提供最终一致性。

23.假如你来设计电商网站的高可用系统,按照CAP理论的要求,你会如何设计?

不同的数据不同的设计。
商品数据库要保证可用性和最终一致性,因为用户最多的操作是浏览商品,这个体验要保证,有时候即使库存更新不及时也无所谓,很容易补救
秒杀的商品要保证一致性和原子性,因为秒杀出现秒杀成功而买不到商品时,用户体验很差
支付和账户余额的数据要保证强一致性和ACID,涉及到钱的数据很关键。

24.请使用FMEA方法分析一下HDFS系统的架构,看看HDFS是如何应对各种故障的,并且分析一下HDFS是否存在高可用问题。

hdfs架构
从0开始学架构课后题
从0开始学架构课后题

25.如果你来设计一个政府信息公开网站的信息存储系统,你会采取哪种架构?谈谈你的分析和理由。

mysql主从读写分离,写操作很少,读取比较多,架构简单,偶尔不可服务也是可以接受,只要能很快恢复就行。

26.既然数据集群就可以做到不同节点之间复制数据,为何不搭建一个远距离分布的集群来应对地理位置级别的故障呢?

远距离的分布集群受限于网络速度和网络不可靠因素,不能做到强一致性,如果一次写入需要客户等待几百毫秒以上,这个集群基本上就是不可用。

27.计算高可用架构从形式上和存储高可用架构看上去几乎一样,它们的复杂度是一样的么?谈谈你的理解。

存储高可用复杂度远高于计算高可用,因为计算高可用基本是无状态的,只要保证服务可用就行,而存储是有状态的,除了可用还要保证正确。

28.假设我们做了前面提到的高可用存储架构中的数据分区备份,又通过自动化运维能够保证1分钟就能将全部系统正常启动,那是否意味着没有必要做异地多活了?

不一定,有的异地多活是为了高可用,有的是为了业务。比如为了响应速度的异地多活,高可用架构是解决不了的。还有些异地多活是规避小概率事件,如地震,城市断电等,这也是高可用架构是解决不了的。

29.异地多活的4大技巧需要结合业务进行分析取舍,这样没法通用,如果底层存储采用OceanBase这种分布式强一致性的数据存储系统,是否就可以做到和业务无关的异地多活?
  1. 要看业务需要什么样的异地多活和什么样的一致性,OceanBase的强一致性和单机DBMS的一致性还是有差异,跨城异地几百毫秒延时的一致性对于一些业务是不可忍受的。
  2. 成本,分布式强一致性成本很高,现在还是只有蚂蚁和一些金融公司使用,可见成本不菲。
30.业务分级讨论的时候,产品说A也很重要,因为影响用户使用;B也很重要,因为影响公司收入;C也很重要,因为会导致客户投诉……这种情况下我们该如何处理业务分级?

以数据说话,根据影响大小排序,在不做异地多活的情况下,影响多少用户,影响程度怎样等等

31.如果你来设计一个整点限量秒杀系统,包括登录、抢购、支付(依赖支付宝)等功能,你会如何设计接口级的故障应对手段?

设计排队抢购功能。

32.规则引擎是常用的一种支持可扩展的方式,按照今天的分析,它属于哪一类?

面向功能拆分,规则引擎从结构上来看也属于微内核架构的一种具体实现

33.为什么互联网企业很少采用SOA架构?

SOA是为企业客户设计解决历史遗留系统而设计的一种架构,互联网企业没有这个问题。

34.你们的业务有采用微服务么?谈谈具体实践过程中有什么经验和教训。

暂无

35. 参考文章中提到的方法,思考一下你所在的业务微服务架构是否还有可以改进和提升的空间?

暂无

36.给你一个由10位Java高级软件工程师组成的开发团队,采用自研的方式,完成所有的微服务基础设施开发,你预测需要多长时间?理由是什么呢?

微服务基础设施包括自动化测试,自动化部署,配置中心,接口框架,api网关,服务发现,服务路由,服务容错,服务监控,服务跟踪,服务安全。
没有什么经验,参考github上spring-cloud-config,100多位贡献者,从开始到1.0release版用了1年多,考虑开源开发效率和后发优势,10位高级工程师开发一个类似spring-cloud-config的程序至少也需要2个月,按这个推算,开发整个基础设施需要2年时间。

37.结合今天所学内容,尝试分析一下手淘Atlas容器化框架是如何实现微内核架构的设计关键点的,分享一下你的理解。

Atlas 是一个 Android 客户端容器化框架,主要提供了组件化、动态性、解耦化的支持。
微内核设计关键点有:插件管理,插件连接和插件通信
Atlas的整体设计,分为五层:
第一层我们称之为Hack层,包括OS Hack toolkit & verifier,这里我们对系统能力做一些扩展,然后做一些安全校验。
第二层是Bundle Framework,就是我们的容器基础框架,提供Bundle管理、加载、生命周期、安全等一些最基本的能力。
第三层是运行期管理层,包括清单,我们会把所有的Bundle和它们的能力列在一个清单上,在调用时方便查找;另外是版本管理,会对所有Bundle的版本进行管理;再就是代理,这里就是和业界一些插件化框架机制类似的地方,我们会代理系统的运行环境,让Bundle运行在我们的容器框架上;然后还有调试和监控工具,是为了方便工程期开发调试。
第四层是业务层了,这里我们向业务方暴露了一些接口,如框架生命周期、配置文件、工具库等等。
最上面一层是应用接入层,就是我们的业务代码了。

看了一些android插件化的资料,这块知识非常缺少,对于altas的设计无法评价。

38.如果业界已经有了一个明显的参照对象(例如电商企业可以参考淘宝),那架构师是否还需要按照步骤逐步演进,还是直接将架构一步到位设计好?

业务规模不一样导致选择的架构不一样。

39.参考今天文章的方法,简单分析一下你所在行业,看看是否存在典型的技术演进模式?

在线广告,主要是商业模式的改变,开始是大流量平台包时段的广告位售卖模式,技术模式就是做一个广告发布平台,再就是搜索关键字广告平台,如Google的adwords,包含了很多小网站,模式更加复杂,需要大规模离线在线学习,然后出现了售卖长尾流量的rtb,实时性要求更高,系统更加复杂。

40.既然存储技术发展到最后都是存储平台,为何没有出现存储平台的开源方案,但云计算却都提供了存储平台方案?

存储平台方案技术不是关键,使用现有各种开源技术就可以搭建存储平台,但是服务不是开源方案可以提供的,包括提供硬件,运维服务,安全服务等等,云计算产商提供了这些服务而成为存储平台方案。

41.使用统一的开发框架和开发语言可以让团队开发效率更高,但这样做会带来什么问题?如何解决?

一种开发框架和一种开发语言不是适合干所有事情的,可以选定一种开发框架和开发语言作为主要选择,在不适宜这种框架和语言的情况下也可以选择其他。

42.为什么可以购买负载均衡和CDN服务,但却不能购买多机房和多中心服务?

异地多活是和数据密切相关的,异地多活的是数据而不是系统,而且成本很高,只有核心数据核心业务才需要。

43.虚拟业务域划分的粒度需要粗一些还是要细一些?你建议虚拟业务域的数量大概是多少,理由是什么?

虚拟业务域划分就是为了解决子系统越来越多而提出的,所以粒度不应该太细,大概的数量在3-8个吧,太少无法体现划分,太多域和域的连接关系数太多。

44.运维平台或者测试平台,有的公司是由中间件团队负责开发,有的是运维和测试团队自己开发,你觉得两种方式各有什么优缺点,分别适用什么场景呢?

按我的理解,中间件团队开发偏向技术,运维团队偏向业务,偏技术的自动化程度更高,偏业务的用户体验更好

45.分析一下你目前开发的系统,你觉得需要架构重构吗?原因和理由是什么?

需要

  1. 业务功能太多,硬编码 – 规则引擎
  2. 出现异常查找困难 – 服务追踪
46.有的人认为:架构师不是技术岗位吗,为何还要做这些事情,沟通和推动的事情让项目经理做就可以了!你怎么看这个观点?

任何一个岗位都有营销的需求,都需要强有力的沟通

47.如果一个架构重构项目最后规划要2年才完成,你会怎么处理?

分步,按节点推进,先搭框架后优化

48.目前的云计算厂商很多都提供了和开源项目类似的系统(例如阿里云的云数据库HBase),你倾向于购买云厂商提供的系统,还是只是将开源系统部署在云服务器上?理由是什么?

购买云服务,节省很多运维,安全的工作,另外云服务器已经提供数据安全备份,如果自己搭建开源系统,选择多份备份,会有极大浪费。

49.你认为App架构接下来会如何演进?谈谈你的思考和分析。

历史总是循环,组件化和容器化的app很重,未来网速够快,app就像一个网址,所有东西都是后端动态生成,如同现在的web一样。

 
 

本文地址:http://www.cvmachine.com/a/question/100351.html
Tags: 开始 架构 课后
编辑:申博开户网
  • 上一篇:Mr.Xu:基础基础基础
  • 下一篇:没有了
  • 关于我们 | 联系我们 | 友情链接 | 网站地图 | Sitemap | App | 返回顶部