【秒懂·云原生】微服务篇 —— 微服务究竟是什么?

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
注册配置 MSE Nacos/ZooKeeper,118元/月
云原生网关 MSE Higress,422元/月
简介: 【秒懂·云原生】微服务篇 —— 微服务究竟是什么?

🔎这里是【秒懂·云原生】,关注我学习云原生不迷路
👍如果对你有帮助,给博主一个免费的点赞以示鼓励
欢迎各位🔎点赞👍评论收藏⭐️

👀专栏介绍

【秒懂·云原生】 目前主要更新微服务,一起学习一起进步。

👀本期介绍

主要介绍什么是微服务、微服务的发展史、微服务与云原生的关系
@[TOC]

👀微服务架构介绍

近年来,微服务架构一直是互联网技术圈的热点之一,越来越多的互联网应用都采用了微服务架构作为系统构建的基础,很多新技术和理念如Docker、Kubernetes、DevOps、持续交付、Service Mesh等也都在关注、支持和跟随微服务架构的发展。

👀微服务架构的发展

从单体应用架构发展到SOA架构,再到微服务架构, 应用架构经历了多年的不断演进。微服务架构不是凭空产生的,而是技术发展的必然结果,分布式云平台的应用环境使得微服务代替单体应用成为互联网大型系统的架构选择。目前,虽然微服务架构还没有公认的技术标准和规范草案,但业界已经有了一些很有影响力的开源微服务架构解决方案,在进行微服务化开发或改造时可以进行相应的参考。

🍖单体应用架构

与微服务架构对比的是传统的单体应用。Web应用程序发展的早期,大部分Web工程是将所有的功能模块打包到一起部署和运行,例如Java应用程序打包为一个war包,其他语言(Ruby、Python或者C++)编写的应用程序也有类似的做法。单体应用的实现架构类似于图中的电影售票系统。

在这里插入图片描述

这个电影售票系统采用分层架构,按照调用顺序,从上到下为表示层、业务层、数据访问(DAO)层、DB层。表示层负责用户体验;业务层负责业务逻辑,包括电影、订单和用户三个模块;数据访问层负责DB层的数据存取,实现增删改查的功能。业务层定义了应用的业务逻辑,是整个应用的核心。在单体应用中,所有这些模块都集成在一起,这样的系统架构就叫做单体应用架构,或称为巨石型应用架构。单体应用是最早的应用形态,开发和部署都很简单。在中小型项目中使用单体应用架构,能体现出其优势,且单体应用的整体性能主要依赖于硬件资源和逻辑代码实现,应用架构自身不需要特别关注。

🍖SOA(面向服务架构)

🎨1、什么是SOA

面向服务的体系结构(Service-Oriented Architecture,SOA)是一个组件模型。

🎨2、为什么要使用SOA

SOA旨在将单个应用程序功能彼此分开,以便这些功能可以单独用作单个的应用程序功能或“组件”。这些组件可以用于在企业内部创建各种其他的应用程序,或者如有需要,对外向合作伙伴公开,以便用于合作伙伴的应用

🎨3、SOA的工作原理

在这里插入图片描述

SOA架构中有三种角色:

服务提供者: 发布自己的服务,并且对服务请求进行响应。
服务注册中心: 注册已经发布的web service,对其进行分类,并提供搜索服务。
服务请求者: 利用服务中心查找所需要的服务,然后使用该服务。

🎨4、面向服务架构的特点

1) 多个单体服务
2)服务间通过ESB间接通讯
在这里插入图片描述
缺点也显而易见:

1)仅垂直方向拆分,每个服务还是单体;

2)引入了ESB庞然大物;

🍖微服务架构

微服务最早是由Martin Fowler与James Lewis于2014年共同提出,需要了解细节的读者可以阅览 https://martinfowler.com/articles/microservices.html。其实Martin先生并没有给出明确的微服务定义,根据其描述,微服务的定义可以概括如下︰微服务架构是一种使用一系列粒度较小的服务来开发单个应用的方式;每个服务运行在自己的进程中;服务间采用轻量级的方式进行通信(通常是HTTP API)﹔这些服务是基于业务逻辑和范围,通过自动化部署的机制来独立部署的,并且服务的集中管理应该是最低限度的,即每个服务可以采用不同的编程语言编写,使用不同的数据存储技术。
如今,微服务架构已经不是一个新概念了,很多业界前沿互联网公司的实践表明,微服务是一种渐进式的演进架构,是企业应对业务复杂性,支持大规模持续创新行之有效的架构手段。

在这里插入图片描述

🎨1、组成

微服务架构是一种比较复杂、内涵丰富的架构模式,它包含很多支撑"微"服务的具体组件和概念,其中一些常用的组件及其概念如下:

  • · 服务注册与发现:
    服务提供方将己方调用地址注册到服务注册中心,让服务调用方能够方便地找到自己;服务调用方从服务注册中心找到自己需要调用的服务的地址。
  • ·负载均衡:
    服务提供方一般以多实例的形式提供服务,负载均衡功能能够让服务调用方连接到合适的服务节点。并且,服务节点选择的过程对服务调用方来说是透明的。
  • ·服务网关: 服务网关是服务调用的唯一入口,可以在这个组件中实现用户鉴权、动态路由、灰度发布、A/B测试、负载限流等功能。
  • ·配置中心:
    将本地化的配置信息(Properties、XML、YAML等形式)注册到配置中心,实现程序包在开发、测试、生产环境中的无差别性,方便程序包的迁移。
  • ·集成框架:
    微服务组件都以职责单一的程序包对外提供服务,集成框架以配置的形式将所有微服务组件(特别是管理端组件)集成到统一的界面框架下,让用户能够在统一的界面中使用系统。
  • ·调用链监控: 记录完成一次请求的先后衔接和调用关系,并将这种串行或并行的调用关系展示出来。在系统出错时,可以方便地找到出错点。
  • ·支撑平台:
    系统微服务化后,各个业务模块经过拆分变得更加细化,系统的部署、运维、监控等都比单体应用架构更加复杂,这就需要将大部分的工作自动化。现在,Docker等工具可以给微服务架构的部署带来较多的便利,例如持续集成、蓝绿发布、健康检查、性能健康等等。如果没有合适的支撑平台或工具,微服务架构就无法发挥它最大的功效。

🎨2、优点

微服务架构模式有很多优势可以有效解决单体应用扩大之后出现的大部分问题。

  • 首先, 通过将巨大单体式应用分解为多个服务的方法解决了复杂性问题。在功能不变的情况下,应用分解为多个可管理的模块或服务。每个服务都有一个用RPC或者消息驱动API定义清楚的边界。微服务架构模式为采用单体式编码方式很难实现的功能提供了模块化的解决方案。由此,单个服务变得很容易开发、理解和维护。
  • 其次, 微服务架构模式使得团队并行开发得以推进,每个服务都可以由专门开发团队来开发。不同团队的开发者可以自由选择开发技术,提供API服务。这种自由意味着开发者不需要被迫使用之前采用的过时技术,他们可以选择最新的技术。甚至于,因为服务都是相对简单的,即使用新技术重写以前的代码也不是很困难的事情。
  • 再次, 微服务架构模式中每个微服务独立都是部署的。理想情况下,开发者不需要协调其他服务部署对本服务的影响。这种改变可以加快部署速度。UI团队可以采用AB测试,快速地部署变化。微服务架构模式使得持续化部署成为可能。
  • 最后, 微服务架构模式使得每个服务易于独立扩展。

👀微服务架构的流派

常见的微服务架构方案有四种,分别是ZeroC lceGrid、基于消息队列、DockerSwarm和Spring Cloud。下面分别介绍这四种方案。

🍖1、ZeroC lceGrid

  • ZeroC lceGrid是基于RPC框架lce发展而来的一种微服务架构,lce不仅仅是一个RPC框架,它还为网络应用程序提供了一些补充服务。lce是一个全面的RPC框架,支持C++、C#、Java、JavaScript、Python等语言。IceGrid具有定位、部署和管理lce服务器的功能,具有良好的性能与分布式能力,下面具体介绍IceGrid的功能。
  • lce的DNS。DNS用于将域名信息映射到具体的IP地址,通过域名得到该域名对应的IP地址的过程叫做域名解析。lceGrid为lce提供了类似的服务∶它允许lce客户端通过简单的名称来查找Ice对象。lce客户端可以通过提供此对象的完整寻址信息来访问服务器中的Ice对象,例如chatRoom1:ssl-h demo.zeroc.com-p10000。这样的硬编码虽然很简单,但缺乏灵活性。因为需要为lce服务器(本例中端口为10000)选择一个固定的端口号,因此将Ice服务器移到不同的主机上需要更新其客户端。
  • lceGrid提供了对这种寻址信息使用符号名称的选项,例如chatRoom1@chatRoomHost。当lce客户端尝试访问chatRoomHost中的对象时,它会要求lceGrid提供与此符号名称关联的实际地址。例如,lceGrid返回-hdemo.zeroc.com-p 65431,客户端就可以直接并透明地连接到服务器。lceGrid架构如图

在这里插入图片描述

🍖2、基于消息队列

在微服务架构的定义中讲到,各个微服务之间使用“轻量级"的通信机制。所谓轻量级,是指通信协议与语言无关、与平台无关。微服务之间的通信方式有两种:同步和异步。同步方式有RPC,REST等;除了标准的基于同步通信方式的微服务架构外,还有基于消息队列异步方式通信的微服务架构。

🍖3、Docker Swarm

Swarm项目是Docker公司发布的三剑客中的一员,用来提供容器集群服务,目的是更好地帮助用户管理多个Docker Engine,方便用户使用。通过把多个Docker Engine聚集在一起,形成一个大的Docker Engine,对外提供容器的集群服务。同时这个集群对外提供Swarm API,用户可以像使用Docker Engine一样使用Docker集群。

🍖4、Spring Cloud

  • Spring Cloud是一个基于SpringBoot实现的云应用开发工具,是一系列框架的集合,当添加这些工具库到应用后会增强应用的行为。SpringBoot秉持约定优于配置的思想,因此可以利用这些组件基本的默认行为来快速入门,并在需要的时候可以配置或扩展,以创建自定义解决方案。
  • Spring Cloud利用Spring Boot的开发便利性,巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等,都可以基于Spring Boot组件进行开发,做到一键启动和部署。Spring Cloud并没有重复制造轮子,它只是将目前比较成熟、经得起实际考验、优秀的开源服务框架组合起来,通过Spring Boot进行封装,屏蔽掉复杂的配置和实现原理,最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

以下为Spring Cloud的核心功能:

  • 分布式/版本化配置
  • 服务注册和发现
  • 服务路由
  • 服务和服务之间的调用
  • 负载均衡
  • 断路器
  • 分布式消息传递

还有很多基础的功能没有列出,每个功能对应Spring Cloud中的一个组件,包括Spring Cloud Config、Spring Cloud Netflix (Eureka、Hystrix、Zuul、Archaius...) . Spring Cloud Bus等组件。

👀云原生与微服务

提及云原生,首先需要了解一下CNCF,即云原生计算基金会,2015年由谷歌牵头成立,基金会成员目前已有一百多个企业与机构,包括亚马逊、微软、思科等巨头。目前CNCF所托管的应用已达14个,知名的项目有Kubernetes、Prometheus、Envoy等。

CNCF宪章中给出了云原生应用的三大特征,概括如下:

  • 容器化封装: 以容器为基础,提高整体开发水平,形成代码和组件重用,简化云原生应用程序的维护。在容器中运行应用程序和进程,并作为应用程序部署的独立单元,实现高水平资源隔离。
  • 动态管理: 通过集中式的编排调度系统来动态管理和调度。
  • 面向微服务: 明确服务间的依赖,互相解耦。

云原生包含了一组应用的模式,用于帮助企业快速、持续、可靠、规模化地交付业务软件。如图所示,云原生由微服务架构、DevOps和以容器为代表的敏捷基础架构组成。

在这里插入图片描述

相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
4天前
|
弹性计算 Kubernetes Cloud Native
云原生架构下的微服务设计原则与实践####
本文深入探讨了在云原生环境中,微服务架构的设计原则、关键技术及实践案例。通过剖析传统单体架构面临的挑战,引出微服务作为解决方案的优势,并详细阐述了微服务设计的几大核心原则:单一职责、独立部署、弹性伸缩和服务自治。文章还介绍了容器化技术、Kubernetes等云原生工具如何助力微服务的高效实施,并通过一个实际项目案例,展示了从服务拆分到持续集成/持续部署(CI/CD)流程的完整实现路径,为读者提供了宝贵的实践经验和启发。 ####
|
3天前
|
Kubernetes Cloud Native 微服务
云原生之旅:从容器到微服务
【10月更文挑战第29天】在这篇文章中,我们将一起探索云原生的奥秘。云原生不仅仅是一种技术,更是一种文化和方法论。我们将从容器技术开始,逐步深入到微服务架构,最后探讨如何在云平台上实现高效的服务部署和管理。无论你是初学者还是有经验的开发者,这篇文章都将为你提供有价值的见解和实用的技能。让我们一起踏上这段激动人心的云原生之旅吧!
|
4天前
|
运维 Kubernetes Cloud Native
云原生之旅:容器化与微服务的融合
【10月更文挑战第28天】 在数字化转型的浪潮中,云原生技术如星辰般璀璨,引领着企业IT架构的未来。本文将带你穿梭于云原生的世界,探索容器化技术和微服务架构如何携手共舞,打造灵活、高效的应用部署和运维模式。我们将通过实际代码示例,揭示这股力量背后的奥秘,并展现它们是如何为现代软件开发带来革新。准备好了吗?让我们启航,驶向云原生技术的深海。
|
4天前
|
Cloud Native 持续交付 云计算
云原生入门指南:从容器到微服务
【10月更文挑战第28天】在数字化转型的浪潮中,云原生技术成为推动现代软件开发的关键力量。本篇文章将带你了解云原生的基本概念,探索它如何通过容器化、微服务架构以及持续集成和持续部署(CI/CD)的实践来提升应用的可伸缩性、灵活性和可靠性。你将学习到如何利用这些技术构建和部署在云端高效运行的应用,并理解它们对DevOps文化的贡献。
14 2
|
10天前
|
监控 Cloud Native Java
云原生架构下微服务治理策略与实践####
【10月更文挑战第20天】 本文深入探讨了云原生环境下微服务架构的治理策略,通过分析当前技术趋势与挑战,提出了一系列高效、可扩展的微服务治理最佳实践方案。不同于传统摘要概述内容要点,本部分直接聚焦于治理核心——如何在动态多变的分布式系统中实现服务的自动发现、配置管理、流量控制及故障恢复,旨在为开发者提供一套系统性的方法论,助力企业在云端构建更加健壮、灵活的应用程序。 ####
55 10
|
5天前
|
Kubernetes Cloud Native API
云原生架构下微服务治理的深度探索与实践####
本文旨在深入剖析云原生环境下微服务治理的核心要素与最佳实践,通过实际案例分析,揭示高效、稳定的微服务架构设计原则及实施策略。在快速迭代的云计算领域,微服务架构以其高度解耦、灵活扩展的特性成为众多企业的首选。然而,伴随而来的服务间通信、故障隔离、配置管理等挑战亦不容忽视。本研究聚焦于云原生技术栈如何赋能微服务治理,涵盖容器编排(如Kubernetes)、服务网格(如Istio/Envoy)、API网关、分布式追踪系统等关键技术组件的应用与优化,为读者提供一套系统性的解决方案框架,助力企业在云端构建更加健壮、可维护的服务生态。 ####
|
6天前
|
监控 安全 Cloud Native
云原生安全:Istio在微服务架构中的安全策略与实践
【10月更文挑战第26天】随着云计算的发展,云原生架构成为企业数字化转型的关键。微服务作为其核心组件,虽具备灵活性和可扩展性,但也带来安全挑战。Istio作为开源服务网格,通过双向TLS加密、细粒度访问控制和强大的审计监控功能,有效保障微服务间的通信安全,成为云原生安全的重要工具。
22 2
|
10天前
|
运维 Cloud Native 持续交付
云原生架构下的微服务设计原则与实践####
【10月更文挑战第20天】 本文深入探讨了云原生环境中微服务设计的几大核心原则,包括服务的细粒度划分、无状态性、独立部署、自动化管理及容错机制。通过分析这些原则背后的技术逻辑与业务价值,结合具体案例,展示了如何在现代云平台上实现高效、灵活且可扩展的微服务架构,以应对快速变化的市场需求和技术挑战。 ####
35 7
|
12天前
|
Kubernetes Cloud Native 云计算
云原生之旅:从容器到微服务的探索之路
【10月更文挑战第20天】在数字化转型的浪潮中,云原生技术成为推动企业创新的重要力量。本文将深入探讨云原生的核心概念、技术架构及其在现代软件开发中的应用,揭示如何通过云原生技术提升业务的灵活性和可扩展性。
|
10天前
|
监控 Cloud Native 持续交付
云原生架构下微服务的最佳实践与挑战####
【10月更文挑战第20天】 本文深入探讨了云原生架构在现代软件开发中的应用,特别是针对微服务设计模式的最优实践与面临的主要挑战。通过分析容器化、持续集成/持续部署(CI/CD)、服务网格等关键技术,阐述了如何高效构建、部署及运维微服务系统。同时,文章也指出了在云原生转型过程中常见的难题,如服务间的复杂通信、安全性问题以及监控与可观测性的实现,为开发者和企业提供了宝贵的策略指导和解决方案建议。 ####
36 5