Architect ABC 01

Suggest search： architect 架构师

0x01 架构师的日常职责是什么?

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

0x02 开发工程师和架构师有何区别?

工作重点不同:

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

能力要求不同:

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

0x03 如何走上架构之路?

• 首先要有架构师的思维，对 1.分布式、2。高并发、3.高性能、4.高可用、5.可扩展、6.松耦合、7.高内聚、8.可复用、9.系统边界、10.安全 等方面有深刻的理解。

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

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

• 掌握好 UML, 提升 1.个人系统分析、 2.系统架构、 3.系统设计、 4.画业务架构图、 5.技术架构图、 6.写架构方案 等方面的能力。

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

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

0x04 业务架构师与基础架构师区别

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

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

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

0x05 UML对系统架构重不重要?

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

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

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

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

0x06 Spring-cloud 和 Dubbo 用哪个?

Dubbo 相对而言，成熟稳定，文档齐全门槛低一些,但是很多服务治理方面的功能是缺失的。

Springcloud 大而全， 但很多功能不强大,不成熟。长期而言，个人更看好 Spring cloud,虽然目前还有一些坑, 而且门槛也比 Dubbo 高，但整体发展趋势比 Dubbo 强，Spring cloud 生态体系比 Dubbo 更好，功能更全面。

掌握 Dubbo 和 Spring cloud 是不冲突的，二者有很多相同的地方，又有很多地方不同。

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

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

0x08 高并发和高性能的区别和联系是什么?

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

QPS Queries Per Second 是每秒查询率 ,是一台服务器每秒能够响应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准, 即每秒的响应请求数，也即是最大吞吐能力。

TPS Transactions Per Second 也就是事务数/秒。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数，

0x09 服务限流有哪些算法?

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

并发计数器

漏桶

令牌桶

0x10 数据同步有哪些方式?

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

0x11 上亿数据如何大规模更新?

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

0x12 dubbo 是否有什么缺陷？

dubbo 缺陷很多呀，特别是 1。服务治理方面，2。服务限流算法有缺陷，3.突发流量有问题的，4.服务熔断才刚刚有，但也有缺陷，监控方面只支持点到点的监控，不能做到分布式链路监控,没有服务网关，服务分组能力太弱。、

dubbo 性能还有提升的空间，编解码不支持messagpack,通信方式有待改进。监控中心功能太简单，监控中心和管理后台没有整合。

dubbo 才刚刚和springcloud打通，支持还不是很友好。

0x13 在分布式环境下，如何防止RocketMQ消息重复消费?

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

0x14 MongoDB 和 Redis 有什么区别?

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

0x15 rocketmq是否会丢消息

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

有两种常见的原因：

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

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

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

0x16 如何做技术选型?

技术选型是个能力活儿，架构师经常做技术选型，会出有答案的选择题，有几种方案，给到技术高管或者开发团队。而不是一上来就是写架构代码。

失职的架构师是给技术领导或者技术团队出问答题，长期出问答题，基本可以走人了。

架构师要有一定的架构功力， 会给领导或技术团队出选择题，总有一款技术适合的，比较每一种技术(方案)的优缺点，技术领导或者技术团队会很喜欢的，以技服人。

架构思路一般是:问题(背景) –>技术调研(选型) –> 规划(方案) –> 落地(擼代码)，任何架构或者技术，都要解决问题的，要有价值。

0x17 那技术选型主要是谁来负责，谁来背锅呢?

谁选谁负责，比如，如果是架构师选的，架构师肯定要负责。技术选型， 要从公司的业务场景，技术多方面去比较每一种技术的优缺点，比如，对于几种MQ，kafka, rocketmq, rabbitmq, activemq, 从 1.技术适用场景， 2.技术的成熟度， 3.技术门槛， 4.可维护性， 5.性能， 6.并发， 7.扩展性等角度去比较

每一种MQ技术在以上多个角度的优缺点，做选型的人，尽量做选择题，比较每一种技术的优缺点， 做到以技服人，让相关人或相关团队，心服口服。

0x18 如何分析需求？

回答这个问题需要牢牢把握这两点：

• 1、需要知道是谁提出的。（问题）
• 2、提出的人为什么会提出这个需求

这需求我们要有一个思维的一个转变，初阶程序员只知道把上级安排的事做了，

问题是你现在就是Leader，你要知道你后面没人了，因此你需要有一个全局的思维。

0x19 业务（项目），技术，架构之间的关系？

• 1、业务是一个目标
• 2、技术实现业务场景
• 3、架构就是整合技术

三者联系：框架是为了适应业务的变化，将更多的技术整合进来，实现一个业务目标.

0x20 如何理解架构师

• 1、架构师的目的就是实现业务的增长
• 2、架构师具备调动资源的权力

补充说明：

• 增长：在原有业务适应未来的变化
• 资源：开发人员 执行
• 如何调动资源？ 根据实际资源情况，动态调整

0x21 微服务和微服务架构关系？

• 1、微服务就是业务拆分
• 2、微服务架构就是对微服务的整合

特点：

• 1、符合单一职责
• 2、微服务内有且只有一个服务
• 3、服务升级不会影响到其他服务

0x22 分布式事务方案如何合理选择，结合场景来说？

4个方面（抽象场景）

• 1、如果是单服务跨数据库 2PC 和 3PC 方案
• 2、如果是不同服务不同数据库 TCC 和 Saga
• 3、如果是不同服务同数据库 TCC 和 Saga
• 4、如果是服务之间异步通讯 本地消息表 cap

EOF