遇到面试官问微服务架构设计到底该如何回答？

正文

请到「今天看啥」查看全文

单体架构达到瓶颈

• 业务复杂度上升，扩展困难，维护费力度上升，牵一发动全身
• 团队规模扩大，开发冲突增多，开发效率降低，无法兼容多种编程语言
• 性能受到制约，在服务可靠性、吞吐能力、服务部署等方面达到瓶颈

优化架构，更新换代

• 保证技术架构的鲜活度，不与主流脱轨
• 不断的调整技术建设，支撑内部技术发展
• 更好的架构体系，更有力的支撑业务需求

跟随潮流，为了微服务而微服务

• 为了紧跟潮流，别人搞我们也要搞
• 为了体验下微服务架构的魅力
• 为了自己实操一把，掌握微服务技术

微服务的出发点必定是为了解决架构层面遇到的问题，微服务是分而治之的思想。它通过引入更分散的架构思想，从而来解决更复杂的系统问题。所以，微服务并不是所有系统都适用的。在考虑微服务架构的时候，我们得先评估下是否真的需要？从单体到微服务是一个复杂化的过程，如果非必要不微服务。最近，大有微服务合并转向单体的趋势。只有我们的系统在业务复杂度层面、系统性能层面、团队开发协作层面等有了确切的需求，那么微服务确实是不二之选。

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://github.com/YunaiV/ruoyi-vue-pro
• 视频教程：https://doc.iocoder.cn/video/

微服务到底是什么？

微服务（Microservices）是一种软件开发架构风格，它将一个复杂的应用程序构建为一系列小型服务的集合，每个服务运行在其独立的进程中，并通常围绕特定的业务能力进行构建。这些服务可以通过定义良好的API进行通信，通常是HTTP RESTful API或轻量级的消息传递系统。

微服务的核心特点包括：

1. 小型化和轻量级：每个服务都相对较小，只关注特定的业务功能。
2. 独立部署：各个微服务可以独立部署，不需要依赖其他服务。
3. 独立扩展：可以根据需求独立扩展或收缩特定的服务。
4. 技术多样性：团队可以根据服务的特定需求选择最适合的技术栈，包括编程语言和数据存储等。
5. 业务中心化：每个服务都围绕一项业务能力构建，易于理解和维护。
6. 敏捷性：微服务架构提高了开发和部署的速度，使得快速迭代和持续交付成为可能。
7. 容错性：系统中某个服务的故障不会导致整个系统的崩溃，提高了系统的稳定性。
8. 去中心化治理：没有统一的控制中心，服务之间的调用和数据流是去中心化的。
9. 去中心化数据管理：每个服务可以有自己的数据库，实现数据的封装和隔离。
10. 基础设施自动化：自动化的部署、扩展、监控和故障恢复是微服务架构的关键。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://github.com/YunaiV/yudao-cloud
• 视频教程：https://doc.iocoder.cn/video/

我们到底如何进行微服务拆分？

拆分是没有完全标准的答案和方式，每家公司或者每个团队拆分的微服务方式可以说是各不相同。但拆分必然有相同的部分，有一些必然需要参考的准则和拆分方式。这些就是我们所需要掌握的，包括面试时候所需要回答出来的点。

微服务拆分原则

1. 单一职责原则：每个服务应该有一个清晰定义的职责，并且只负责一个特定的业务功能。
2. 业务能力对齐：服务应该围绕业务能力构建，确保每个服务都是一个可独立部署和扩展的业务单元。
3. 独立性：每个服务应该是独立的，拥有自己的代码库、数据库和部署流程。
4. 轻量级通信：服务之间的通信应该是轻量级的，避免使用重量级的通信协议。
5. 数据隔离：每个服务应该有自己的数据存储，避免服务之间的数据依赖。
6. 去中心化治理：允许每个服务独立选择技术栈和框架。
7. 容错性：服务应该能够容忍其他服务的故障，通常通过断路器模式实现。
8. 敏捷性：服务应该能够快速迭代和部署，以适应快速变化的业务需求。
9. 智能端点和哑管道：服务之间通过简单的管道通信，而业务逻辑应该封装在端点中。
10. API 网关：使用API网关来提供统一的入口，处理跨服务的请求路由、负载均衡和安全控制。
11. 持续集成和持续部署（CI/CD） ：自动化的构建和部署流程对于微服务架构至关重要。
12. 监控和日志：实现集中的监控和日志管理，以便于跟踪和诊断跨服务的问题。
13. 团队自治：每个服务的开发团队应该有足够的自治权，以快速响应业务需求。
14. 服务发现：实现服务发现机制，以便服务实例可以相互发现并进行通信。
15. 断路器模式：使用断路器模式来防止级联故障，并提高系统的稳定性。
16. 异步消息传递：在可能的情况下，使用异步消息传递来解耦服务。
17. 版本控制：为服务和API实现版本控制，以支持向后兼容性。
18. 安全性：确保每个服务都有适当的安全措施，包括认证和授权。
19. 文档和API管理：为API提供详细的文档，并管理API的变更。
20. 避免远程调用：尽量避免远程服务调用，优先考虑本地服务调用。
21. 服务边界清晰：服务之间的边界应该清晰定义，避免功能重叠。
22. 避免共享服务：避免创建共享服务，因为它们可能导致服务间的耦合。
23. 可替换性：设计服务时，应考虑到将来可能的替换或升级。
24. 环境一致性：确保开发、测试和生产环境尽可能一致，以减少环境差异导致的问题。
25. 配置管理：实现集中的配置管理，以便于跨服务的配置变更。
26. 服务契约：定义清晰的服务契约，包括API和数据格式。
27. 性能和可伸缩性：在设计服务时，考虑性能和可伸缩性需求。
28. 避免过度拆分：避免过度拆分服务，导致过多的服务管理和通信开销。

请到「今天看啥」查看全文