1. 建筑师的日常职责是什么？

一般来说，架构师负责软件领域的顶层设计。 架构师需要根据公司的发展规划公司未来几年的架构，制定可实施的架构方案，解决技术问题，进行技术选型和研究，实现具体架构。 优秀的架构师既能创建架构解决方案，又能编写具体的架构代码。

2. 开发工程师和架构师有什么区别？

工作侧重点不同：架构师侧重于前期架构规划，需要根据公司业务场景、团队技术水平等制定可实施的架构方案、进行技术选型、解决技术问题等； 而开发工程师则专注于具体的功能。特别是，开发工程师专注于实现具体的功能。

能力要求不同：架构师要求比较高。 他们需要具备架构的广度和深度，掌握一系列架构技术栈，有架构实践经验，具有较强的系统分析、系统架构、系统设计能力。 主要要求开发工程师熟悉基础技术栈，熟悉相关业务，快速实现产品的相关功能。

3、如何走上建筑之路？

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

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

童鞋的发展中非常缺少注重建筑技术的实践。 建议大家多和架构师交流，多实践相关技术，注重实际实践才能快速成长。 理论实践一次胜过读一百遍。

掌握UML，提高个人系统分析、系统架构、系统设计、绘制业务架构图、技术架构图、编写架构方案等方面的能力。

从架构思维、架构技术栈、架构职责等角度撰写架构师简历，重点关注个人掌握的架构技术栈，突出项目的架构亮点和难点。

公司内部进行架构改造，或者去其他公司进行架构改造。 在建筑面试中多练习。 如果你没有经验，可以请有经验的建筑师模拟几轮面试。

4. 业务架构师和基础设施架构师的区别

对于Java程序员来说，架构师分为两类：业务架构师和基础架构师。 从高级开发到业务架构师的过渡很容易，并且很快就能取得成果。 业务架构和基础设施70%是相同的架构师 简历，即都需要架构能力。 剩下的30%是业务架构需要熟练业务、制定架构方案、实施架构，而基础设施则需要100%纯技术。 短期看来，基础设施更加繁荣，但事实并非如此。 业务架构的发展前景比较好，因为35岁以后，重要的是综合能力，而不是纯粹的架构能力。 业务架构需要有较好的沟通能力、架构规划、架构实施能力、一定的行业业务背景，甚至管理能力，所以从业务架构成为技术总监或者CTO比较容易。 如果你一直做基础设施，你可能就是总架构师。 一般来说，有经验的架构师是业务架构师和基础设施架构师。 找工作很容易，他们唱什么歌都可以。

5. UML对于系统架构重要吗？

UML是架构的基本技能，但却很容易被开发人员忽视。 架构师必须具备较强的系统分析、系统架构、系统设计、架构表达能力。 这些能力可以通过掌握UML来提高。 业务架构师可以通过UML抽象出业务平台的核心用例，并可以通过分析模型清晰地表达复杂的业务流程。 在高层设计阶段，可以使用包图、组件图、部署图来清晰地表达设计和部署。 基础架构师设计中间件时，可以绘制UML协作图或活动图来表达技术功能的流程。 在设计阶段，他们可以绘制封装图来表达每个封装的功能。 然后多人可以共同研究技术中间件的具体代码并做出具体的结构实现。

6. 我应该使用Springcloud还是Dubbo？

Dubbo相对成熟稳定，文档齐全，门槛较低，但缺少很多服务管理功能。 Springcloud庞大且全面，但很多功能并不强大且不成熟。 从长远来看，我更看好Spring cloud。 虽然还存在一些陷阱，门槛比Dubbo高，但整体发展趋势比Dubbo更强。 Spring云生态系统比Dubbo更好，功能更全面。 掌握Dubbo和Spring cloud并不冲突。 它们有很多相似点和不同点。

7、分布式定时任务和普通任务有什么区别？

分布式计划任务一般允许多个服务器同时运行计划任务。 效率比普通任务高，可用性比普通任务高（可以做故障转移，架构上不存在单点问题，任务节点可以监控），性能比普通任务强（该架构具有高度可扩展性，多台机器一起运行，执行时间更短），支持的并发量远大于普通任务（多台机器执行，海量数据可以分配到不同的机器上执行，并发性非常好） ）。

8、高并发和高性能有什么区别和联系？

简单来说，高并发是访问次数，高性能是访问响应时间，两个不同的角度。 并发量化的常见参数指标有qps、tps等，性能量化指标一般是处理时间。 例如，如果接口响应时间为10ms和5分钟，性能就完全不同。 100qps和50万qps的并发架构是完全不同的。 如果架构不合理，并发越大，性能越差。 如果架构合理的话，并发量对性能基本没有影响，只需增加更多的机器即可，软件架构不需要任何改变。

9. 为什么项目经理在中国实际上是一个非常危险的职业？

项目管理实际上没有什么价值。 项目经理的工作其实可替代性很强，可以被产品经理、技术经理、核心开发人员等其他利益相关者所替代。 尤其是中年后，项目经理很难找到合适的工作。

10.reactor线程指的是reactor模型的哪一部分？

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

11. RabbitMQ是目前最常用的消息中间件吗？

技术选型是从技术使用场景、优缺点等方面综合评估，很多公司都使用RocketMQ和kafka，kafka基本上是大数据的选择。

12、业务限流算法有哪些？

常见的服务限流算法有并发计数器算法、漏桶算法、令牌桶算法等。 前两种算法不支持突发限流，而令牌桶算法支持突发限流。 一般使用Google Guava来实现令牌桶算法，使用sentinel作为服务限流的中间件。

13. 数据同步有哪些方式？

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

14、如何大规模更新亿级数据？

您可以利用分布式任务调度中间件的大任务分片，将亿级数据分发到多台机器上。 如果实时性要求不高，可以设置一定的时间间隔，以减轻DB压力； 如果实时性要求高，则需要将数据层划分为数据库。 如果每天增量数据较多，可以考虑定期对数据进行归档。

15、dubbo有什么缺陷吗？

Dubbo 有很多缺陷，尤其是在服务治理方面。 服务限流算法有缺陷，存在突发流量问题，刚推出服务断路器，但也有缺陷。 监控方面，仅支持点对点监控，无法分布式。 链路监控，无业务网关，业务分组能力太弱。 dubbo性能还有提升空间。 编解码器不支持messagepack，通信方式有待改进。 监控中心功能过于简单，监控中心与管理后台未整合。 Dubbo刚刚连接springcloud，支持还不是很友好。

16、分布式环境下，如何防止RocketMQ消息的重复消费？

消费者可以基于分布式锁解决rocketmq的消息幂等性问题。 使用分布式锁可以实现rocketmq消息消费的幂等性，从纯技术角度讲messageid架构师 简历，或者从业务角度讲业务主键的唯一性。 另外，rocketmq生产者发送消息时，它本身保证了消息的幂等性。 最主要的是消费者在消费消息时必须保证幂等性。

17.MongoDB和Redis有什么区别？

定位不同。 前者是基于分布式文件存储的数据库，后者是缓存。 很多公司禁止使用redis作为数据库。 一般来说，有经验的架构团队会规定缓存过期时间最多设置为7天。 如果超过7天，热点数据将重新生成。

18. RocketMQ会丢失消息吗？

RocketMQ一般不会丢失消息。 所谓的rocketmq消息丢失有两个常见原因。 1、开发者编写的消费者代码逻辑存在Bug。 比如消费消息的代码逻辑有异常，但是异常被吃掉了。 ，并返回成功状态，人为造成消息丢失。 2、运维层面存在问题。 将消息写入分布式存储时出现问题，导致消息丢失。 这两种情况导致所谓的消息丢失，第一种是最常见的，很多童鞋开发者都犯了第一个错误。

19. Spring cloud 和 Dubbo 应该使用哪一个？

Dubbo相对成熟稳定，文档齐全，门槛较低，但缺少很多服务治理功能。 Spring Cloud庞大且全面，但很多功能并不强大且不成熟。 长远来看，我更看好Spring Cloud。 虽然还存在一些陷阱，门槛比dubbo高，但总体发展趋势比dubbo更强。 Spring Cloud生态系统比dubbo更好，功能更全面。 掌握dubbo和spring cloud并不冲突。 它们有很多相似点和不同点。 另外，阿里巴巴技术团队开发了spring-cloud-alibaba，为dubbo向spring-cloud靠拢、融合做技术准备。

20、如何进行技术选型？

技术选型是一项基于技能的工作。 架构师经常进行技术选型，并向技术主管或开发团队提供多项选择题、答案和多个选项。 而不是从一开始就编写架构代码。 架构师失职就是向技术领导或者技术团队提出问题。 如果他问的时间长了，他基本上就可以离开了。 建筑师必须具备一定的建筑技能。 他们会给领导或技术团队提出多项选择题。 总有一种技术适合。 比较每种技术（解决方案）的优缺点。 技术领导或者技术团队一定会非常喜欢。 说服人们。 架构思路一般是：问题（背景）--》技术研究（选型）--》规划（解决方案）--》实现（代码）。任何架构或技术必须能解决问题，才有价值。

21.谁主要负责技术选型，谁来承担责任？

谁选择谁就负责。 比如说，如果架构师选择了，那么架构师就必须负责。 在选择技术时，需要从公司的业务场景和技术方面来比较每种技术的优缺点。 比如MQ、kafka、rocketmq、rabbitmq、activemq这几种类型，需要考虑技术的适用场景、技术的成熟度、技术的优劣。 从门槛、可维护性、性能、并发性、可扩展性等角度来比较以上各个MQ技术的优缺点，做选择者尽量采取选择题来比较各技术的优缺点每项技术。 用你的技能说服人们并说服相关的人或团队。

22.如何走上建筑之路？

1、首先要有架构师的心态，对分布式、高并发、高性能、高可用、可扩展性、松耦合、高内聚、可重用、系统边界、安全性等有深刻的理解。 2.技术 必须基础广泛，熟悉架构技术栈，如：熟悉微服务、缓存、分布式消息中间件、分布式任务中间件、数据层中间件、分布式监控中间件、网关中间件、分布式配置中心等，不所有的技术栈都需要非常精通，但重要的技术必须掌握得非常深入。 3、注重架构技术的实践，这在童鞋的发展中是非常缺失的。 建议大家多和架构师交流，多实践相关技术，注重实际实践才能快速成长。 理论实践一次胜过读一百遍。 4、熟练掌握UML，提高个人系统分析、系统架构、系统设计、绘制业务架构图、技术架构图、编写架构方案的能力。 5、从架构思维、架构技术栈、架构职责等角度写出一篇好的论文。 一个架构师的简历，重点介绍个人掌握的架构技术栈，突出项目的架构亮点，难度6.在公司内部改造架构，或者去其他公司改造架构。 在建筑面试中多练习。 如果你没有经验，可以请有经验的建筑师模拟几轮面试。

23. 日常设计中是否使用领域驱动模型？

不推荐，尤其不适合互联网公司。 理解驱动设计是美国发明的一种设计方法。 它旨在为复杂业务分层代码。 不推荐，因为门槛很高。 我个人认为不适合国内国情，特别是不适合互联网的敏捷发展。 不适合互联网的敏捷开发。 对开发人员的素质要求非常高。 贫血模型、充血模型、失血模型、血肿模型非常复杂。 推导式设计会使代码分层更加复杂，开发效率低于传统的四层代码分层。 我工作的一家公司之前实行了洞察驱动设计，但效果不佳，后来改为传统的四层模型。 当时，一位架构师同事主导了领域驱动设计的实现。 代码分层效果不好。 开发人员在实现实际代码时存在很多困惑，容易出现混乱，开发效率不高。 一个好的架构就是简单。 只有简单易用的架构才有生存空间。