Java架构师职位常见面试题，你掌握了多少？

在编程领域，架构师这个职位是相当一部分程序员理想的职位了，一般都成为架构师，绝大多数人都是技术非常牛，在项目开发阶段也很有可能有着相当了不起的战功，他们也是由普通的程序员一步步的走来的，对于你遇到的问题他们可能一下就能找到解决办法，不是因为他们聪明，很有可能是这些问题，这些坑他们都是踩过的，他们算是过来人了，总之没有一定的实战经验与阅历智慧是不太可能成为架构师的。

对于大多数程序员来说，都还没有做过架构师，也只是略略与架构师打过交道，但是对于架构师的具体工作可能也只是了解一个皮毛，一名合格的架构师需要具备哪些技能，这些大多数人应该还比较好奇，那么架构师的日常工作是什么呢？近期一名网友就发帖问起了这个问题，那么我们就不妨就这个问题探讨一下，首先，先看看其他网友们都是怎么说的吧！

网友一：大部分都是搞点新词汇给大家普及普及

上世是朵花：说的有点轻松了，如果从表面说的确是新词汇，如果从本质来说是新的技术思想，对整个技术团队的技术上的提升，引领公司的技术方向有着重要的作用。

网友二：我个人观点，在现在这个技术大爆炸时代，其实各个问题都有了很成熟的技术解决方案。在未来，纯粹的技术架构师很难立足，架构师必须熟悉业务，会沟通协调，会跪舔，并以技术为特长，其他能力全面发展。我觉得这是一个趋势。

上世是朵花：同意这名网友的部分观点，架构师在技术的学习上一定是不能松懈的，一定要保持自己的技术与时代同步，技术落后的架构师势必会被淘汰。

网友三：大部分在开会……

上世是朵花：只是一个表面现象。不算是主要工作。

网友四：现在普通架构大点的厂应该都是大头兵，深蹲一线干活

上世是朵花：是的，有的公司架构师还在一线编码，但是都是一些比较关键的核心代码。

网友五：印象中的架构师，搭框架，写公共方法，一些高级的码代码工作。

上世是朵花：这个一般是新启动的项目，可大多数项目都是有成熟稳定的框架了。

网友六：大部分时间在写文档和PPT

上世是朵花：这里的文档更偏向于设计层面，是需要大量思考的，写文档只是一种形式而已，并不是写流水文那么简单。

网友七：架构本身隔一段时间才调整一次，平常当业务变更导致各个组件都要修改时，协调制定修改方案，如何兼容，先上线哪部分后上线哪部分。

上世是朵花：对于大部分公司，你说这个更类似于研发经理的工作。

网友八：提升性能，开发稳定高效的中间件，解决疑难问题(绝大部门人解决不了那种)，开源库替换验证，设计开发通用的基础组件和高级代码，重构架构和设计(向着高内聚低耦合的目标)

上世是朵花：没错，算是架构师的部分工作吧。

其实关于架构师的工作也并非那么的固定，根据公司的情况不一样，架构师所做的工作与架构师所处的地位也是不尽相同，在有一些小的公司，架构师仍旧是在一线编码，他们除了编码，他们还是需要解决疑难问题，只要是技术上问题，普通开发人员解决不了的他们就得上，不会把程序员的工作与架构师的工作分得那么清楚，当然，有这样经历的架构师技术能力也是很强的，都是得意于这种艰苦环境塑造出来的，大一点公司，架构师的工作就可能相对规范一点，主要参与系统的架构调整及规划，一些技术选型的都需要他们去做，另外，有的公司架构师的职位就和CTO差不多了，关于技术上事情，他们是比较有权威的，当然，这也与个人的一些特点有关，职位高再加上能张罗一些事情，爱出头，擅于扛事，所处的地位自然也会比现有的职能还要高。

一.架构师的日常职责是什么?

总体而言，架构师负责软件领域的顶层设计。架构师需要 根据公司的发展，规划企业未来若干年的架构，制定可落地的架构方案，解决

技术难题，做技术选型与攻关,落地具体的架构。优秀的架构师既能做架构方案，也能写具体的架构代码。

二、开发工程师和架构师有何区别?

工作重点不同:架构师重点在于前期的架构规划，需要制定可落地的架构方案，结合公司的业务场景、团队的技术水平等因素做技术选型，解决技术难题等等;而开发工程师重点在于具体的落地，特别的，开发I程师的工作重点落地具体的功能。

能力要求不同:架构师要求比较高，要有架构的广度、深度,需要掌握一系列的架构技术栈，要求有架构实战经验，要有很强的系统分析、系统架构、系统设计的能力。开发工程师主要是要求熟悉基本的技术栈，熟悉相关业务，快速落地产品的相关功能。

三、如何走上架构之路?

●首先要有架构师的思维，对分布式、高并发、高性能、高可用、可扩展、松耦合、高内聚、可复用、系统边界、安全等方面有深刻的理解。

●技术面要广，熟悉架构技术栈，比如:熟悉微服务,缓存，分布式消息中间件，分布式任务中间件，数据层中间件，分布式监控中间件，网关中间件,分布式配置中心等等，并不是所有的技术栈要非常精通，但重要的技术，- 定要掌握得非常深。

●注重架构技术实践，这是开发童鞋非常缺失的。建议多和架构师多交流，多落地相关技术的实践，集中火力多实战成长会很快的。理论看100遍，不如实践-遍。

●掌握好uml,提升个人系统分析、 系统架构、系统设计、画业务架构图、技术架构图、写架构方案等方面的能力。

●从架构思维，架构技术栈，架构职责等角度写好一 份架构师的简历，重点突出个人掌握的架构技术栈，重点突出项目的架构亮点，难点。

●在企业内部转架构，或者去别的企业转型架构。架构面试方面多实践，如果没经验，可以让架构师老司机们多模拟面试几轮。

四、业务架构师与基础架构师区别

对于java程序猿而言，架构师分为业务架构师，基础架构师两大类，从高级开发转成业务架构师，难度小，出成绩快。业务架构和基础架构有70%是一样的，那就是都要求有架构能力，剩下的30%是业务架构要求熟练掌握业务，制定架构方案，架构落地，基础架构则是100%要求纯技术。

短期而言，看似基础架构更风光，其实不然。业务架构发展前景更好-些，因为35岁以后，拼的是综合能力，不再是纯架构能力。业务架构要求有更好的沟通能力，架构规划，架构落地能力，-定的行业业务背景，甚至管理能力，所以从业务架构更容易做到技术总监或cto。

如果一直 做基础架构，那么可能是首席架构师。-般的架构老司机是业务架构，基础架构通吃的，好就业，到什么山唱什么歌。

五、UML对系统架构重不重要?

UML是架构基本功，但又容易被开发童鞋忽视。

架构师要有很强的系统分析，系统架构，系统设计，架构表达能力，通过掌握UML,提高这些能力。

业务架构师通过UML可以抽象出业务平台的核心用例，可以把复杂的业务流程以分析模型表达清楚，高阶设计阶段，利用包图，组件图，部署图把设计，部署表达清楚。

基础架构师设计中间件，可以画uml协作图， 或活动图表达技术功能的流程，设计阶段，可以画包图，表达各个包的功能，然后多人可以-起撸技术中间件的具体代码，做具体架构落地。

六、Springcloud和Dubbo用哪个?

Dubbo相对而言，成熟稳定，文档齐全门槛低一些,但是很多服务治理方面的功能是缺失的。Springcloud大而全， 但很多功能不强大,不成熟。长期而言，个人更看好Spring cloud,虽然目前还有一些坑, 而且门槛也比Dubbo高，但整体发展趋势比Dubbo强，Spring cloud生态体系比Dubbo更好，功能更全面。掌握Dubbo和Spring cloud是不冲突的，二者有很多相同的地方，又有很多地方不同。

七、分布式定时任务和一般的任务都什么区别?

分布式定时任务-般是多台服务器可以同时跑定时任务，效率要比一般的任务高，可用性要比一般的任务高(可以做失效转移，架构上没有单点问题，任务节点可以监控)，性能要比一般任务的强(架构是强伸缩性，多台机器-起运行，执行时间要短)，支持的并发能力远远超过一般的任务(多台机器执行，可以把海量数据分配给不同的机器执行，并发能力非常好)

八、高并发和高性能的区别和联系是什么?

简单而言，高并发是访问数量，高性能是访问响应时间，两个不同的角度。并发量化的常见参数指标，qps,tps等等 ，性能量化指标一般是处理时间，比如:接口响应时间是10ms和5分钟，性能是完全不-样的。 qps为100和qps为50万的并发架构完全不-样。如果架构不合理，并发量越大，性能越差。如果架构合理，并发量的大小对性能基本没影响，加机器即可，软件架构不需要任何改变。

九、为啥项目经理在国内其实是很危险的职业?

项目管理其实没啥含金量，项目经理工作替代性其实很强，可以被产品经理，技术经理，核心开发等干系人替代。特别是到中年以后，项目经理很难找到合适的工作。

十、reactor线程指的是reactor模型中的哪个部分?

这个问题本身是有问题的。reactor线程模型分为单线程， 多线程，主从多线程。实际编程过程中， 第二种用的是最多的，

十一、消息中间件目前使用频率最大是RabbitMQ吗?

技术选型是从技术的使用场景，优缺点等方面综合评估的。很多企业用RocketMQ和katfka,大数据基本100%选kafka.

十二、服务限流有哪些算法?

服务限流常见算法有并发计数器算法，漏桶算法，令牌桶算法。前两种算法不支持突发流量的限流，令牌桶算法支持突发流量的限流。一般用谷歌guava落地令牌 桶算法,用sentinel作为服务限流的中间件。

十三、数据同步有哪些方式?

这个问题其实涉及到很多场景的。如果是数据库方面的，可以用SqlLoader. GoldenGate等相关工 具同步数据;大数据方面的， 可以用ETL、Hadoop等相关技术同步数据; 如果是定时调度发起的，可以考虑用SpringBatch, Quartz, Elastic-Job等分布式任务 中间件发起同步数据;如果是异步的场景，可以用mq来实现监听并且同步增量数据。大批量的数据情况下， 尽可能地考虑用mq、线程池、多线程、数据批量操作等相关技术手段提升性能。

十四、上亿数据如何大规模更新?

可以用分布式任务调度中间件的大任务分片来做，把上亿的数据分给多台机器来做。如果实时性要求不高， 完全可以设置一定的时间间隔，减少DB压力;如果实时要求高，数据层需要分库。如果每天增量数据较多,可以考虑周期性地做数据归档。

十五、dubbo是否有什么缺陷？

dubbo缺陷很多呀，特别是服务治理方面，服务限流算法有缺陷，突发流量有问题的，服务熔断才刚刚有，但也有缺陷，监控方面只支持点到点的监控，不能做到分布式链路监控,没有服务网关，服务分组能力太弱。dubbo性能还有 提升的空间，编解码不支持messagpack,通信方式有待改进。监控中心功能太简单，监控中心和管理后台没有整合。dubbo才 刚刚和springcloud打通，支持还不是很友好。

十六、在分布式环境下，如何防止RocketMQ消息重复消费?

消费方可以基于分布式锁来解决rocketmq的消息幂等性的问题。用分布式锁可以从纯技术角度messageid，或者业务角度业务主键唯一性都可以实现rocketmq消息消费的幕等性。另外，rocketmq生产方发送消息，本身就保证了消息的冪等性，主要是消费方消费消息要保证幂等性。

十七、MongoDB和Redis有什么区别?

定位不-样，前者是基于分布式文件存储的数据库，后者是缓存，很多公司是禁止把redis当数据库来使用的，一般而言，有经验的架构团队会规定把缓存失效时间至多设置为7天。超过7天，再重新生成热点数据。

十八、rocketmq是否会丢消息

rocketmq-般是不会丢消息，所谓的rocketmq丢消息

有两种常见的原因：

1、开发童鞋写的消费者代码逻辑有bug,比如，消费消息的代

码逻辑有异常，却把异常吃掉了，且返回成功的状态，人为的导致丢消息

2、运维层面有问题，把消息写到分布式存储有问题，导致丢消息。这两种情况导致所谓的丢消息，以第一种居多，有不少开发童鞋会犯第一种错误。

十九、Spring cloud和dubbo用哪个?

dubbo相对而言，成熟稳定，文档齐全门槛低一些，但是很多服务治理方面的功能是缺失的。spring cloud大而全,但很多功能不强大,不成熟。长期而言，个人更看好spring cloud, 虽然目前还有一些坑， 而且门槛也比dubbo高，但整体发展趋势比dubbo强，spring cloud生态体系比dubbo更好，功能更全面。掌握dubbo和spring cloud是不冲突的，二者有很多相同的地方，又有很多地方不同。并且阿里技术团队开发了spring-cloud-alibaba,为dubbo向spring-cloud靠拢， 整合做了技术准备。

二十、如何做技术选型?

技术选型是个能力活儿，架构师经常做技术选型，会出有答案的选择题，有几种方案，给到技术高管或者开发团队。而不是一上来就是写架构代码。失职的架构师是给技术领导或者技术团队出问答题，长期出问答题，基本可以走人了。架构师要有一定的架构功力， 会给领导或技术团队出选择题，总有一款技术适合的，比较每一种技术(方案)的优缺点，技术领导或者技术团队会很喜欢的，以技服人。架构思路一般是:问题(背景)--》技术调研(选型) --》规划(方案) --》 落地(擼代码)，任何架构或者技术，都要解决问题的，要有价值。

二十一、那技术选型主要是谁来负责，谁来背锅呢?

谁选谁负责，比如，如果是架构师选的，架构师肯定要负责。技术选型， 要从公司的业务场景，技术多方面去比较每一种技术的优缺点，比如，对于几种MQ，kafka, rocketmq, rabbitmq, activemq, 从技术适用场景，技术的成熟度，技术门槛，可维护性，性能，并发，扩展性等角度去比较每一种MQ技术在以上多个角度的优缺点，做选型的人，尽量做选择题，比较每一种技术的优缺点， 做到以技服人，让相关人或相关团队，心服口服。

二十二、如何走上架构之路?

1、首先要有架构师的思维，对分布式、高并发、高性能、可用、可扩展、松耦合、高内聚、可复用、系统边界、安全等方面有深刻的理解

2、 技术面要广，熟悉架构技术栈，比如:熟悉微服务，缓存，分布式消息中间件,分布式任务中间件，数据层中间件,分布式监控中间件，网关中间件，分布式配置中心等等，并不是所有的技术栈要非常精通，但重要的技术，一定要掌握得非常深

3、 注重架构技术实践，这是开发童鞋非常缺失的。建议多和架构师多交流，多落地相关技术的实践，集中火力多实战成长会很快的。理论看100遍,不如实践一遍。

4、掌握好um,提升个人系统分析、系统架构、系统设计、画业务架构图、技术架构图、 写架构方案等方面的能力

5、从架构思维，架构技术栈,架构职责等角度写好一份架构师的简历， 重点突出个人掌握的架构技术栈，重点突出项目的架构亮点，难点

6、在企业内部转架构，或者去别的企业转型架构。架构面试方面多实践，如果没经验，可以让架构师老司机们多模拟面试几轮。

二十三、领域驱动模型平时设计的时候用不用?

不建议用，特别不适合互联网企业。领悟驱动设计是老美发明的一套设计方法论，针对复杂的业务,进行代码分层，不建议用，门槛很高，个人认为不太适合国内的国情，特别不适合互联网的敏捷开发,它对开发人员的素质要求很高。贫血模型，充血模型，失血模型，胀血模型这些模型很复杂、很绕,领悟驱动设计会把代码分层做的比较复杂，开发效率比传统的四层代码分层的效率要低。我以前工作过的-家公司实施过领悟驱动设计，效果差，后来还是改为传统的四层模型。当时有-位架构师同事牵头落地的领域驱动设计的代码分层效果并不好，开发人员落地实际代码有很多困惑，容易产生混乱，开发效率也不高。好的架构是大道至简，简单、易用的架构才有生存空间。