整体而言，架构师负责软件领域的顶层设计。 架构师须要根据公司的发展，规划企业将来若干年的架构，制定可落地的架构方案，解决技术难题，作技术选型与攻关，落地具体的架构。优秀的架构师既能作架构方案，也能写具体的架构代码。java
工做重点不一样：架构师重点在于前期的架构规划，须要制定可落地的架构方案，结合公司的业务场景、团队的技术水平等因素作技术选型，解决技术难题等等；而开发工程师重点在于具体的落地，特别的， 开发工程师的工做重点落地具体的功能。react
能力要求不一样：架构师要求比较高，要有架构的广度、深度，须要掌握一系列的架构技术栈，要求有架构实战经验，要有很强的系统分析、系统架构、系统设计的能力。 开发工程师主要是要求熟悉基本的技术栈，熟悉相关业务，快速落地产品的相关功能。面试
对于java程序猿而言，架构师分为业务架构师，基础架构师两大类，从高级开发转成业务架构师，难度小，出成绩快。业务架构和基础架构有70%是同样的，那就是都要求有架构能力，剩下的30%是业务架构要求熟练掌握业务，制定架构方案，架构落地，基础架构则是100%要求纯技术。短时间而言，看似基础架构更风光，其实否则。业务架构发展前景更好一些，由于35岁之后，拼的是综合能力，再也不是纯架构能力。业务架构要求有更好的沟通能力，架构规划，架构落地能力，必定的行业业务背景，甚至管理能力，因此从业务架构更容易作到技术总监或cto。若是一直作基础架构，那么多是首席架构师。通常的架构老司机是业务架构，基础架构通吃的，好就业，到什么山唱什么歌。redis
UML是架构基本功，但又容易被开发童鞋忽视。架构师要有很强的系统分析，系统架构，系统设计，架构表达能力，经过掌握UML，提升这些能力。业务架构师 经过 UML能够抽象出业务平台的核心用例，能够把复杂的业务流程以分析模型表达清楚，高阶设计阶段，利用包图，组件图，部署图把设计，部署表达清楚。基础架构师设计中间件，能够画uml协做图，或活动图表达技术功能的流程，设计阶段，能够画包图，表达各个包的功能，而后多人能够一块儿撸技术中间件的具体代码，作具体架构落地。算法
Dubbo相对而言，成熟稳定，文档齐全门槛低一些，可是不少服务治理方面的功能是缺失的。Springcloud大而全，但不少功能不强大，不成熟。长期而言，我的更看好Spring cloud,虽然目前还有一些坑，并且门槛也比Dubbo高，但总体发展趋势比Dubbo强，Spring cloud生态体系比Dubbo更好，功能更全面。掌握Dubbo和Spring cloud是不冲突的，两者有不少相同的地方，又有不少地方不一样。spring
分布式定时任务通常是多台服务器能够同时跑定时任务，效率要比通常的任务高，可用性要比通常的任务高(能够作失效转移，架构上没有单点问题，任务节点能够监控)，性能要比通常任务的强（架构是强伸缩性，多台机器一块儿运行，执行时间要短），支持的并发能力远远超过通常的任务（多台机器执行，能够把海量数据分配给不一样的机器执行，并发能力很是好）。数据库
简单而言，高并发是访问数量，高性能是访问响应时间，两个不一样的角度。 并发量化的常见参数指标，qps,tps等等，性能量化指标通常是处理时间，好比:接口响应时间是10ms和5分钟，性能是彻底不同的。qps为100和qps为50万的并发架构彻底不同。若是架构不合理，并发量越大，性能越差。若是架构合理，并发量的大小对性能基本没影响，加机器便可，软件架构不须要任何改变。编程
项目管理其实没啥含金量，项目经理工做替代性其实很强，能够被产品经理，技术经理，核心开发等干系人替代。特别是到中年之后，项目经理很难找到合适的工做。缓存
这个问题自己是有问题的。 reactor线程模型分为单线程，多线程，主从多线程。 实际编程过程当中，第二种用的是最多的，安全
技术选型是从技术的使用场景，优缺点等方面综合评估的。不少企业用RocketMQ和kafka,大数据基本100%选kafka.
服务限流常见算法有并发计数器算法，漏桶算法，令牌桶算法。前两种算法不支持突发流量的限流，令牌桶算法支持突发流量的限流。 通常用谷歌guava落地令牌桶算法，用sentinel做为服务限流的中间件。
这个问题其实涉及到不少场景的。 若是是数据库方面的，能够用SqlLoader、GoldenGate等相关工具同步数据； 大数据方面的，能够用ETL、Hadoop等相关技术同步数据；若是是定时调度发起的，能够考虑用SpringBatch，Quartz，Elastic-Job等分布式任务中间件发起同步数据；若是是异步的场景，能够用mq来实现监听而且同步增量数据。 大批量的数据状况下，尽量地考虑用mq、线程池、多线程、数据批量操做等相关技术手段提高性能。
能够用分布式任务调度中间件的大任务分片来作，把上亿的数据分给多台机器来作。 若是实时性要求不高，彻底能够设置必定的时间间隔，减小DB压力；若是实时要求高，数据层须要分库。若是天天增量数据较多，能够考虑周期性地作数据归档。
dubbo缺陷不少呀，特别是服务治理方面，服务限流算法有缺陷，突发流量有问题的，服务熔断才刚刚有，但也有缺陷，监控方面只支持点到点的监控，不能作到分布式链路监控，没有服务网关，服务分组能力太弱。dubbo性能还有提高的空间，编解码不支持messagpack，通讯方式有待改进。监控中心功能太简单，监控中心和管理后台没有整合。dubbo才刚刚和springcloud打通，支持还不是很友好。
消费方能够基于分布式锁来解决rocketmq的消息幂等性的问题。用分布式锁能够从纯技术角度messageid,或者业务角度业务主键惟一性均可以实现rocketmq消息消费的幂等性。另外，rocketmq生产方发送消息，自己就保证了消息的幂等性，主要是消费方消费消息要保证幂等性。
定位不同，前者是基于分布式文件存储的数据库，后者是缓存，不少公司是禁止把redis当数据库来使用的，通常而言，有经验的架构团队会规定把缓存失效时间至多设置为7天。超过7天，再从新生成热点数据。
rocketmq通常是不会丢消息，所谓的rocketmq丢消息，有两种常见的缘由，一、开发童鞋写的消费者代码逻辑有bug,好比，消费消息的代码逻辑有异常，却把异常吃掉了，且返回成功的状态，人为的致使丢消息。二、运维层面有问题，把消息写到分布式存储有问题，致使丢消息。 这两种状况致使所谓的丢消息，以第一种居多，有很多开发童鞋会犯第一种错误。
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技术在以上多个角度的优缺点，作选型的人，尽可能作选择题，比较每一种技术的优缺点，作到以技服人，让相关人或相关团队，心服口服。
一、首先要有架构师的思惟，对分布式、高并发、高性能、高可用、可扩展、松耦合、高内聚、可复用、系统边界、安全等方面有深入的理解 二、技术面要广，熟悉架构技术栈，好比:熟悉微服务，缓存，分布式消息中间件，分布式任务中间件，数据层中间件，分布式监控中间件，网关中间件，分布式配置中心等等，并非全部的技术栈要很是精通，但重要的技术，必定要掌握得很是深 三、注重架构技术实践，这是开发童鞋很是缺失的。建议多和架构师多交流，多落地相关技术的实践，集中火力多实战成长会很快的。理论看100遍，不如实践一遍。 四、掌握好uml,提高我的系统分析、系统架构、系统设计、画业务架构图、技术架构图、写架构方案等方面的能力 五、从架构思惟，架构技术栈，架构职责等角度写好一份架构师的简历，重点突出我的掌握的架构技术栈，重点突出项目的架构亮点，难点 六、在企业内部转架构，或者去别的企业转型架构。架构面试方面多实践，若是没经验，可让架构师老司机们多模拟面试几轮。
不建议用，特别不适合互联网企业。领悟驱动设计是老美发明的一套设计方法论，针对复杂的业务，进行代码分层，不建议用，门槛很高，我的认为不太适合国内的国情，特别不适合互联网的敏捷开发，它对开发人员的素质要求很高。贫血模型，充血模型，失血模型，胀血模型这些模型很复杂、很绕，领悟驱动设计会把代码分层作的比较复杂，开发效率比传统的四层代码分层的效率要低。我之前工做过的一家公司实施过领悟驱动设计，效果差，后来仍是改成传统的四层模型。当时有一位架构师同事牵头落地的领域驱动设计的代码分层效果并很差，开发人员落地实际代码有不少困惑，容易产生混乱，开发效率也不高。好的架构是大道至简，简单、易用的架构才有生存空间。