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等）的架构发展案例，分析一下其发展过程，看看哪些地方体现了这三条架构设计原则。

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

2011年加入移动端：

合适优于业界领先
目前的架构：

演化优于一步到位

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架构

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一样。