微服务架构对比

本文探讨了三种服务发现模式:传统集中式代理、客户端嵌入式代理和主机独立进程代理。每种模式都有其优缺点,适用于不同的场景。例如,集中式代理常见于大型企业,客户端代理在互联网公司流行,而主机独立进程代理则是一种折中方案。

一、服务发现:服务的消费方(Consumer)如何发现服务的提供方(Provider)?

二、负载均衡:服务的消费方如何以某种负载均衡策略访问集群中的服务提供方实例?

三种服务发现模式

服务发现和负载均衡并不是新问题,业界其实已经探索和总结出一些常用的模式,这些模式的核心其实是代理(Proxy,如下图所以),以及代理在架构中所处的位置,

 

 

在服务消费方和服务提供方之间增加一层代理,由代理负责服务发现和负载均衡功能,消费方通过代理间接访问目标服务。根据代理在架构上所处的位置不同,当前业界主要有三种不同的服务发现模式:

模式一:传统集中式代理

 

这是最简单和传统做法,在服务消费者和生产者之间,代理作为独立一层集中部署,由独立团队(一般是运维或框架)负责治理和运维。常用的集中式代理有硬件负载均衡器(如F5),或者软件负载均衡器(如Nginx),F5(4层负载)+Nginx(7层负载)这种软硬结合两层代理也是业内常见做法,兼顾配置的灵活性(Nginx比F5易于配置)。

这种方式通常在DNS域名服务器的配合下实现服务发现,服务注册(建立服务域名和IP地址之间的映射关系)一般由运维人员在代理上手工配置,服务消费方仅依赖服务域名,这个域名指向代理,由代理解析目标地址并做负载均衡和调用。

国外知名电商网站eBay,虽然体量巨大,但其内部的服务发现机制仍然是基于这种传统的集中代理模式,国内公司如携程,也是采用这种模式。

模式二:客户端嵌入式代理 </

### SOA 架构微服务架构的区别和比较 #### 定义对比 SOA(面向服务的架构)是一种软件设计模式,旨在通过定义良好的接口和服务契约来促进不同应用程序间的互操作性。而微服务架构则更进一步,不仅限于服务间通信的概念,而是将整个应用分解成一系列小型、独立的服务,每个服务专注于单一业务功能[^1]。 #### 组件粒度 在SOA中,服务通常是较大规模的企业级服务,可能涉及多个业务流程;而在微服务架构,服务被细分为更加具体的小型单元,即所谓的“微”服务,它们各自负责特定的功能模块,并能够单独部署和扩展[^2]。 #### 数据管理方式 对于SOA而言,数据往往集中存储在一个或少数几个大型数据库中,由各个服务共享访问权限;相比之下,在微服务环境中实现了数据去中心化的理念——各微服务拥有自己私有的持久化机制,可以选择最适合其需求的数据管理和存储解决方案(如关系型数据库SQL或是非关系型数据库NoSQL),从而减少了跨服务调用时产生的依赖性和复杂度[^3]。 #### 通信协议 传统意义上的SOA倾向于使用重量级的消息传递标准和技术栈,比如Web Services (SOAP), XML-RPC等;然而现代微服务体系结构偏好轻量级RESTful API以及异步消息队列作为主要通讯手段,这有助于提高系统的灵活性并降低延迟时间。 #### ESB vs API Gateway 企业服务总线(Enterprise Service Bus, ESB)是SOA中的核心概念之一,用于连接不同类型的应用程序和服务,提供中介层来进行转换、路由等功能。但在微服务世界,API网关承担起了类似的角色,不过它的职责更为聚焦于入口流量控制、负载均衡等方面的工作,而不是像ESB那样试图成为所有内部交互的核心枢纽。 ```python # 示例代码展示如何配置简单的Flask RESTful API服务器 from flask import Flask app = Flask(__name__) @app.route('/api/v1/resource', methods=['GET']) def get_resource(): return {"message": "This is a microservice endpoint"} if __name__ == '__main__': app.run(debug=True) ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值