导言: 记得自己最早接触类似‘微服务’的理念和实践是在2013年写一个工业级IM系统,当时向往和学习的对象就是腾讯系。特别是腾讯大讲堂中一期《微信之道-至简》对自己的架构理念影响很深,比如下图(1)中体现的就是微服务的设计思想。我也是仿照此架构,设计了我们的IM系统架构。
图(1)
后来,基于这种核心架构和相关实现支撑了企业的一些用户级和设备级服务,并在GitHub上开源一个简化的微服务框架项目,这算是自己对微服务最初也是较浅的理解和实用期。
再后来,在经历子业务众多、逻辑复杂、且多产品线的互联网/物联网平台级产品的长期迭代中,对微服务有了更多的使用和实践,对微服务的拆分、微服务的治理也有了更多的理解和实践。近两年在数字化和云原生的实践中微服务理念已然成为“基础中的基础”,我们对微服务相关开源生态的拥抱也热烈了起来。
再再后来,就是今天的这篇文章,本是面向团队内部的微服务培训指南,也综合了很多其他优秀的三方内容,独乐乐不如众乐乐,分享给大家参考学习。包含三部分:
- 讲解微服务核心理念的“微服务概述”;
- 微服务的拆分和落地方法论:DDD(领域驱动设计);
- 开源微服务治理框架的选择;
一、微服务概述
1. 服务架构的演进
图 服务架构的演进
2. 微服务
微服务是一种分布式软件架构。使用微服务架构可以将一个大型应用程序按照业务或功能模块拆分成多个独立自治的微服务,每个微服务仅实现一种业务或功能,具有明确的边界。为了让各个微服务之间协同工作,它们之间需要通过互相调用或REST等形式的标准接口进行通信和数据交换,是一种松耦合的交互形式。
2.1微服务的优点
- 单一职责:微服务架构中的每一个服务,都应是符合高内聚、低耦合和单一职责原则的业务逻辑单元。不同的微服务通过互相调用REST等形式的标准接口,进行灵活地通信和组合,从而构建出大的应用系统。
- 简化复杂应用:微服务的单一职责原则要求一个微服务只负责一项明确的业务,相对于构建一个可以完成所有任务的大型应用程序,理解和实现只提供一个功能的小型应用程序要容易得多。每个微服务单独开发,可以加快开发速度,使服务更容易适应变化和新需求的出现。
- 独立自治:每个微服务都应该是一个独立的组件,它可以被独立部署、测试、升级和发布,应用程序中的某个或某几个微服务被替换时,其他的微服务都不应该被影响。基于分布式计算、可弹性扩展和组件自治的微服务,与云原生技术相辅相成,为应用程序的设计、开发和部署提供了极大便利。
- 简化应用部署:在单体的大型应用程序中,即使只修改某个模块的一行代码,也需要对整个系统进行重新构建、部署、测试和交付。而在微服务架构中,则可以单独对指定的服务进行构建、部署、测试和交付。
- 可灵活组合:在微服务架构中,可以根据不同的目的组合不同粒度的服务为客户提供应用功