一、架构师的日常职责是什么 ？
总体而言，架构师负责软件领域的顶层设计。 架构师需要根据公司的发展，规划企业未来若干年的架构，制定可落地的架构方案，解决技术难题，做技术选型与攻关，落地具体的架构。优秀的架构师既能做架构方案，也能写具体的架构代码。

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

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

三、 如何走上架构之路？
首先要有架构师的思维，对分布式、高并发、高性能、高可用、可扩展、松耦合、高内聚、可复用、系统边界、安全等方面有深刻的理解 。
技术面要广，熟悉架构技术栈，比如:熟悉微服务，缓存，分布式消息中间件，分布式任务中间件，数据层中间件，分布式监控中间件，网关中间件，分布式配置中心等等，并不是所有的技术栈要非常精通，但重要的技术，一定要掌握得非常深 。
注重架构技术实践，这是开发童鞋非常缺失的。建议多和架构师多交流，多落地相关技术的实践，集中火力多实战成长会很快的。理论看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和kafka,大数据基本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、掌握好uml,提升个人系统分析、系统架构、系统设计、画业务架构图、技术架构图、写架构方案等方面的能力 5、从架构思维，架构技术栈，架构职责等角度写好一份架构师的简历，重点突出个人掌握的架构技术栈，重点突出项目的架构亮点，难点 6、在企业内部转架构，或者去别的企业转型架构。架构面试方面多实践，如果没经验，可以让架构师老司机们多模拟面试几轮。

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