一句话导读
微服务是一种架构模式，英文翻译 microservice，微服务架构的核心理念是将大型、复杂的单体应用拆分成更小的、自治的组件，每个组件即为一个微服务
目录
一、微服务的定义
微服务（Microservice）是一种以服务为中心的软件架构模式，按照我们之前文章的讨论，他是为了解决单体应用复杂度问题的一个手段，将复杂的单体应用，通过不同的方法拆分成合理的一系列微小的服务，每个服务负责一个特定的业务功能，可以独立开发、部署和扩展，独自为一个进程，可以是不同的语言开发，服务间采用轻量级的通讯协议如http、消息队列等进行交互，多个服务组合形成一个微服务体系，服务间松耦合并高度自治。
二、微服务的特点
1.独立性
每个微服务都是独立的应用单元，可以独立部署和运行。这使得团队可以独立开发和扩展服务，而不会对其他服务造成影响。
2.松耦合
微服务之间使用轻量级的通信机制进行交互，从而实现了松耦合。这使得服务之间的变更和演化更加容易，不会影响其他服务的正常运行。
3.可伸缩性
由于每个微服务都可以独立扩展，可以根据实际需求调整每个服务的资源和容量，从而实现更好的可伸缩性。
4.技术多样性
微服务架构允许不同的服务使用不同的技术栈和编程语言，这使得团队可以选择最适合其业务需求和技术能力的技术。
5.独立部署
由于微服务独立部署，可以更快地进行部署和发布新功能，从而实现持续交付和快速响应业务需求。
三、微服务的利与弊
1.优点
降低复杂度：将大型工程分而治之，每个微服务只关注某一个领域
独立开发部署：每个微服务都可以由不同的团队独立开发和部署，使得团队具有更大的自治权和快速迭代能力
技术选型不受限制：各自团队可以根据自己团队的技术特点，选择合适的技术栈完成开发，只要遵循统一的接口协议即可
服务可以独立扩展：微服务要求服务间松耦合，相互独立，各自拥有自己的数据库，无状态接口，这使得服务可以独立扩展，不受限制
故障隔离：由于微服务是独立不是的，一个微服务的故障不会影像到其他微服务的正常运行，提高了整个系统的稳定性
2.弊端
服务拆分是难题：如何做服务拆分，服务之间的边界在哪里，如何做到松耦合，这些问题都是比较棘手的问题
项目整体管理难：对于一个大型项目，如果项目被拆分出几十上百个小服务、小团队，各自拥有自己的管理风格和技术栈，要想整体管理该项目，那将是一个大的项目管理工程。
服务发现与治理难：随着服务数量的增加，服务发现和治理变得更加困难，需要引入额外的组件和机制来管理服务。
服务通信开销增大：微服务之间的通信可能涉及网络开销，特别是在服务数量庞大时，可能会导致性能问题
数据一致性难保证：由于每个微服务都有自己的数据存储，数据一致性成为一个挑战，需要采取合适的解决方案来确保数据一致性。
跨服务测试和调试难：在微服务架构中，跨服务的测试和调试可能变得复杂，需要合理的测试策略和工具。
四、微服务架构典型示例
拿我们上篇博客《02单体应用真的是地狱吗》中国的例子来说，小王和小任的教育APP发展到一定阶段，业务是越来越复杂，最后他们是考虑用微服务来解决这个问题，将服务拆分成了认证服务、用户服务、口算服务、打卡服务、订单服务、商城服务、报表服务等等，伴随着业务的不对发展，后续肯定还有新的服务出现。如下图，微服务架构是一个体系，涵盖了服务注册、配置、治理、调用、监控等等。
图1 微服务典型架构
1793
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
