典型回答 MVC是一种软件设计模式，他的目标是将应用程序的不同部分解耦，使其更容易维护和扩展。 ✅什么是MVC 三层架构是一种软件架构模式，或者说是一种代码分层结构。通常用于构建大型应用程序，如企业级应用或Web应用。 三层架构的主要目标是将不同的关注点分离，以便更容易管理和维护应用程序，同时提供更好的可扩展性和重用性。 MVC和三层架构之间要说有关系的话，那可能就是都是和3有关吧。。。 总结一下吧： MVC 是一种设计模式，通常用于用户界面开发，而三层架构是一种更广泛用于整个应用程序的软件架构。 MVC 将应用程序分为模型、视图和控制器，重点在用户界面和用户交互，而三层架构将应用程序分为表示层、业务逻辑层和数据访问层，强调业务逻辑和数据处理。 MVC 和三层架构并不是互斥的，可以结合使用。例如，在三层架构中使用MVC来处理用户界面的部分是很常见的。
典型回答 所谓单元，是指一个能完成所有业务操作的自包含集合，在这个集合中包含了所有业务所需的所有服务，以及分配给这个单元的数据。 单元化架构就是把单元作为系统部署的基本单位，在全站所有机房中部署数个单元，每个机房里的单元数目不定，任意一个单元都部署了系统所需的所有的应用，数据则是全量数据按照某种维度划分后的一部分。 所以，在单元化架构中，分成很多个单元和一个中心。每个单元之间都是相互独立的。一个单元中完整的部署了一整套业务，如电商交易，金融支付，一次用户操作可以在一个单元内部完成，不需要跨单元执行。 但是如果从数据角度来说， 单元内的数据又不是完整的，他只包含这个单元内的数据，其他的单元的数据他是没有的。 所以，多个单元组合在一起，数据才是完整的。比如我们可以把一个淘宝， 分成3个单元，如上海单元、北京单元和新加坡单元。 这样，一个杭州的用户下单，就可以直接路由到上海单元，并且在这个单元内把所有流程都走完，一个美国的用户下单，就会路由到新加坡单元，并在这个单元完成所有操作。并且杭州的用户的数据只在上海单元中有，美国用户的数据只保存在新加坡单元中。 除了单元以外， 一般还有一个中心的概念，中心的数据就是全量的，所有单元的数据的聚合在一起，都存放在中心上，也会有一部分用户可以路由到中心进行业务操作。 做了单元化以后，一次下单要经过的交易系统、支付系统、数据库、缓存、MQ等等，这些都是在本单元内部独立部署的，所有的请求都不需要跨单元，在单元内部封闭执行完成，可以大大的降低网络的延迟。 并且，做了单元化以后非常方便的扩容，可以在单元内部快速扩容，不会影响到其他单元，也可以直接增加一个新的单元。都有非常好的扩展性。 做了多单元之后，就可以天然实现异地多活，具有很好的容灾性。在用户访问的时候，就可以就近原则，可以得到更快地响应。 当然，单元化也存在一些问题和限制： ...
典型回答 这个问题，很宽泛，很多人不知道该咋回答。其实，架构分好几种，面试很工作中经常聊的就是以下这几个 业务架构 技术架构 部署架构 数据架构 业务架构（首选） 这个是最经常聊的，所谓业务架构其实就是项目的业务功能模块、业务流程。也是面试的时候重点主要应该讲的。 一般需要包括的内容： 核心业务域或者模块或者微服务的划分（如用户、订单、商品、支付） 业务流程图（如下单、退款、发货流程） 业务用例或场景分析 一般建议大家通过一个核心流程来介绍，比如说我的数藏项目我会这么介绍他的业务架构： 这个项目是一个微服务的项目，根据业务功能模块，我们划分出来了网关、用户、交易、订单、商品、区块链、支付等等核心模块，其中比较重要的就是交易、订单、商品、支付等模块。 拿用户的一次下单操作来举例，最开始流量会先到网关，网关经过负载均衡之后会到交易模块，交易模块会做一些前置校验，之后开始和商品、订单等模块做交互，去扣减库存和创建订单等等的。 技术架构（首选） 技术架构其实就是聊技术了，主要是你的技术选型、通信方式、主要的技术栈等等，需要包括： 技术栈选型（Java/Spring Cloud、Go、Node.js 等） 系统分层（如表示层、服务层、数据访问层） 服务间调用方式（REST、RPC、MQ） 架构模式（微服务、DDD、CQRS、Serverless） 中间件选型（缓存、消息队列、搜索、网关等） 还是拿说我的数藏项目我会这么介绍他的技术架构： 这是一个基于Spring Cloud搭建的分布式系统，通过SpringCloud Gateway我们搭建了一个统一的网关，然后各个微服务之间我们采用Dubbo做RPC的调用，异步消息这部分我们用了RocketMQ，存储的话主要用到了Redis做缓存，MySQL做持久化，定时任务采用的时XXL-JOB来实现的。项目中的一些海量数据的查询使用到了ElasticSearch来做的，里面的数据是通过Canal做同步的。还有一些限流相关的我们用了Sentinel实现。分布式事务这部分我们用了Seata作为分布式事务的协调组件。当然，项目中还有Nacos，包括我们的Gateway、Dubbo、Seata、Sentinel等等都依赖他来做注册中心和配置中心的。 部署架构（非主动问不用提） 所谓部署架构，其实就是介绍你的项目是如何部署的。主要需要包括 云/本地部署结构（如公有云、私有云、K8s） 微服务部署情况 主从/集群架构（如数据库、Redis） 灰度发布、自动扩缩容 比如你是否使用了容器，比如k8s等，然后是多少个微服务，多少台机器，是否用异地多活，多机房之类的，比如一些关键的中间件，是否有集群，主从等等，如Redis，MySQL，Kafka等等。 这个面试时的问的比较少的，不主动问的话不要聊，你容易聊不明白，这个偏运维了。 数据架构（非主动问不用提） 数据架构其实就是你系统中的数据结构、数据流、存储方式。比如 数据的存储形式，如Redis、ES、mysql等 是否有分库分表、读写分离策略 是否有数据仓库、数据湖、数据中台 实时处理（Flink）、离线分析（Hive/Spark） 数据资产治理（血缘、元数据、权限） 重点的一些包括数据的存储，比如哪些数据在数据库，哪些数据在redis，哪些又用了ES。然后是否有数仓，包括实时数仓、离线数仓等，以及你的一些实时处理，比如Flink的链路，离线的任务如spark啥的。
典型回答 技术债务（Technical Debt）指的是在开发过程中，为了快速交付或避免解决问题所需的高成本和高风险而采取的妥协或折中方案，这些方案所留下的技术上的负担和后续成本即被称为技术债务。 技术债务的本质是以速度和时间为代价，在软件开发中的某个时刻实施了不可持续的技术决策，通常是为了实现某种业务目标而对代码质量、架构设计、技术选型等方面进行了妥协。虽然技术债务能够让团队在短时间内快速交付软件产品，但随着时间的推移，技术债务会越积越多，导致软件系统越来越难以维护和升级，进而影响业务的持续发展和创新。 为了避免技术债务的积累，开发团队需要尽可能遵循良好的软件开发规范，采用可持续的软件开发方法，关注代码质量和可维护性，并在合适的时机进行技术债务的偿还，即对之前的技术债务进行重构、优化或更新，以保持软件系统的健康发展。
典型回答 分离关注点（Separation of Concerns）：系统中的不同模块应该专注于自己的职责，并与其他模块进行解耦，避免模块之间的耦合度过高，增加系统的可维护性和可扩展性。 单一职责原则（Single Responsibility Principle）：每个模块或者组件应该只负责一个职责或者任务，这样可以减少模块之间的相互影响，提高代码的可读性和可维护性。 开放封闭原则（Open-Closed Principle）：系统的设计应该对扩展开放，对修改关闭，通过接口的定义，使得系统能够在不修改原有代码的情况下进行扩展和修改。 接口隔离原则（Interface Segregation Principle）：系统中的接口应该只包含必要的方法，避免接口过于庞大，减少系统的复杂度。 依赖倒置原则（Dependency Inversion Principle）：高层模块不应该依赖于低层模块，而应该依赖于抽象接口，通过接口实现高低层的解耦，提高系统的可维护性和可扩展性。 最少知识原则（Least Knowledge Principle）：模块之间的通信应该尽可能少，一个模块只应该了解那些与之直接交互的模块，避免模块之间的耦合度过高，降低系统的复杂度。 重构（Refactoring）：系统的设计应该不断进行重构，保持系统的灵活性和可维护性。通过对系统的分层、模块化、组件化等方式，减少代码的冗余和重复，提高系统的可读性和可维护性。 高内聚低耦合原则：模块内部的元素之间应该紧密关联，而与外部的联系应该尽量松散。 分层架构原则：将系统分解成若干个层次，每个层次负责一种特定的功能。 模块化原则：将系统分解成若干个模块，每个模块负责一种特定的功能。模块之间应该是松散耦合的。
典型回答 罗列几个架构设计的时候需要考虑的一些要素，因为不同的业务可能侧重点不一样，比如金融对安全性、一致性要求更高。 模块化：将整个系统拆分成若干个模块，每个模块具有独立的功能和职责，以便于管理和维护。 可扩展性：系统应该能够快速、容易地扩展以适应业务的不断变化。 高可用性：系统应该设计为高可用性，能够在故障情况下快速恢复，保证业务的连续性。 可维护性：系统应该易于维护和管理，包括故障排除、监控、日志记录等方面。 安全性：系统应该保证数据的安全性和隐私性，防止未经授权的访问和攻击。 性能优化：系统应该具备良好的性能，能够在高并发情况下快速响应并处理请求。 简单性：系统应该尽可能地简单化，降低系统的复杂度，易于开发和维护。 可测试性：系统应该易于测试和验证，包括单元测试、集成测试、性能测试等方面。
典型回答 架构设计的过程中，往往需要在多个目标之间进行权衡，以找到最优的设计方案。这些目标可能包括系统的可扩展性、可维护性、性能、安全性、可靠性、易用性、成本等等。由于这些目标有时候是相互矛盾的，因此需要在不同目标之间进行权衡。
典型回答 存储亿级商品需要考虑以下几个方面问题： 存储方式：亿级商品的存储一般使用分布式存储技术，例如分布式文件系统、分布式对象存储或者分布式数据库。这样可以保证数据的可靠性和高可用性。一般可以考虑像TiDB、Oceanbase等。 数据分片：当数据量达到亿级时，需要考虑数据的分片，将数据分散存储在多个节点上，以提高查询效率和并发处理能力。可以根据商品的属性（如品牌、类别、价格等）进行分片，或者按照商品ID的哈希值进行分片。常见的做法就是分库分表。 数据缓存：对于热门的商品数据，可以将其缓存在内存或缓存数据库中，以提高查询速度和响应时间。常用的缓存技术包括Redis、Memcached等。 数据备份与恢复：需要建立完善的数据备份和恢复机制，以保证数据的安全性和可靠性。可以采用冷备份、热备份或者增量备份等方式进行备份，以便在数据出现故障或丢失时能够及时恢复。 数据索引与优化：对于亿级商品的查询，需要进行索引优化和性能调优，以提高查询效率和响应速度。可以采用多种索引技术（如B+树、哈希索引等），或者进行数据的预处理、缓存、批处理等优化方式。 适当归档：对于一些非热点数据，如过期商品等内容，可以适当的做一些归档存储。 数据压缩：对于一些可以被压缩的数据，可以采用压缩技术来减少数据存储空间，降低存储成本。
典型回答 一个好的架构应该具备以下特点： 易于理解和维护：架构应该易于理解，遵循良好的设计原则，使得代码易于维护和更新。 可扩展性：架构应该能够在需要时方便地扩展，而不会影响现有的代码。 可靠性：架构应该是可靠的，避免单点故障，提供数据冗余和故障恢复机制。 高性能：架构应该能够处理大量的请求，具有高性能和可伸缩性，以满足业务需求。 安全性：架构应该具备安全性，对系统的机密数据和操作进行保护，避免安全漏洞和攻击。 灵活性：架构应该具有灵活性，允许对业务需求的变化做出快速响应，以提高业务的敏捷性和创新能力。 易于部署和升级：架构应该易于部署和升级，允许快速部署新功能和修复问题，同时确保不中断服务。 成本效益：架构应该是成本效益的，避免过度设计和过度工程，同时保证系统的可靠性和性能。 架构，一定是服务于业务的，所以，他需要能够适应不断变化的业务需求和技术发展。同时，好的架构需要遵循良好的设计原则和软件工程实践，以确保软件的质量和可维护性。 最后，架构没有好坏之分，只有适不适合，所谓好与坏只是不同的历史背景下的一个客观评判。适合的架构就是好架构。
典型回答 架构既是设计出来的，也是演进出来的。设计+演进，缺一不可。 在开始一个项目时，架构通常需要被设计出来，以确保系统具有所需的特性、可扩展性、可靠性和安全性。然而，随着项目的不断发展和演进，架构也可能需要随之进行调整。这可能是由于需求的变化、系统性能问题的发现、技术进步、以及其他各种原因。 因此，好的架构不仅需要从一开始就进行充分的设计规划，还需要通过不断的演进来持续地改进和完善。架构的设计和演进是一种动态的过程，需要不断地评估和调整，以确保系统能够持续地满足业务需求和用户需求。