KOI 后台新的架构下,webshop如何消费后台服务 - websocket 初始化

简介: KOI 后台新的架构下,webshop如何消费后台服务 - websocket 初始化

本文介绍图中绿色方框,Web shop是如何消费backend提供的微服务的。

打开backend-ms repository的miniWebShop.html:

通过这行代码建立和Web Socket服务器的连接:

var socket = io(‘ws://127.0.0.1:8877’);

通过socket.emit API向Web服务器发送一个action,名称为requestFromWebShop, action的负载为oData。

545c85b94220f8194ef9e752893faf8f_format,png.png

通过socket.on即可接收到后台服务器的处理结果。

这个on后面的action名称需要前端和后台服务器达成一致。


要深入解析这行 JavaScript 代码 var socket = io('ws://127.0.0.1:8877');,我们需从几个方面着手:var 关键字的用途io 函数及其参数的含义,以及 ws://127.0.0.1:8877 这一部分的作用。通过这些方面的解读,可以全面理解代码的功能和背后的原理。


var 关键字

在 JavaScript 中,var 关键字用于声明变量。尽管 ES6 引入了 letconst 作为更加现代的变量声明方式,var 依然在很多遗留代码中使用。letconst 相比,var 声明的变量具有函数作用域(如果在函数内部声明)或者全局作用域(如果在函数外部声明),而不是块作用域。这意味着,使用 var 声明的变量可以在声明它的函数的任何地方被访问,或者如果它没有在函数内部声明,那么就可以在全局环境中访问。


io 函数及其参数

io 函数通常与 Socket.IO 库一起使用。Socket.IO 是一个用于实现实时、双向和基于事件的通信的 JavaScript 库。它不仅可以运行在浏览器中,还能被用在 Node.js 服务器上。io 函数的调用初始化了一个到服务器的 Socket.IO 连接。


var socket = io('ws://127.0.0.1:8877'); 这行代码中,io 函数接受一个参数,即服务器的 URL。通过这个 URL,客户端知道应该连接到哪个服务器以及通过哪个端口进行通信。


ws://127.0.0.1:8877 的含义

ws://127.0.0.1:8877 指定了 WebSocket 服务的地址和端口号。ws:// 是 WebSocket 协议的前缀,类似于 HTTP 的 http://HTTPS 的 https://127.0.0.1 是一个特殊的 IP 地址,代表本机地址,也就是说,它指向的是当前设备。8877 是服务监听的端口号。


WebSocket 是一种网络通信协议,它提供了全双工通信渠道,这意味着客户端和服务器可以在建立连接后随时相互发送数据,而无需像传统的 HTTP 请求那样,每次通信都需要一个请求和一个响应。Socket.IO 库使用 WebSocket 作为其底层传输机制之一,但如果必要,它也可以回退到较老的长轮询方法以保持兼容性。


通过 io('ws://127.0.0.1:8877') 的调用,我们实际上是在请求与位于 127.0.0.1 的服务器上的 8877 端口建立一个 WebSocket 连接。Socket.IO 会处理实际的连接细节,包括连接的建立、数据的传输以及错误处理等。


Socket.IO 的工作原理

Socket.IO 通过封装 WebSocket 提供了一种高效、可靠的实时通信方式。它自动处理了许多底层细节,如握手、心跳检测、断线重连以及编码和解码消息等。开发者只需关注于发送和接收消息即可。


在客户端和服务器建立连接后,双方可以自由地发送 JSON、二进制文件或者任何想要的数据类型。Socket.IO 通过事件来处理通信,这意味着发送和接收数据都是通过监听和触发事件来实现的。例如,一个聊天应用可能会使用 message 事件来接收新消息。


在实践中的应用

假设你正在开发一个需要实时功能的网页应用,比如一个在线聊天应用或者一个多玩家在线游戏。通过使用 var socket = io('ws://127.0.0.1:8877'); 这样的代码行,你能够在客户端建立起一个与服务器的实时连接。一旦连接建立,你就可以开始实时地发送和接收数据了。


总结起来,这行代码背后的原理和应用展示了 JavaScript 和 Socket.IO 在实时网络通信领域的强大能力。它不仅减少了开发者在网络编程方面的负担,还大大提高了应用的交互性和用户体验。

相关文章
|
11天前
|
UED
服务架构中的数据驱动设计
【5月更文挑战第13天】数据驱动设计是依据用户数据进行网页设计的方法,旨在通过测试了解用户需求并优化体验,从而增加流量和转化率。设计师应避免主观感受影响设计,因个人偏好可能与用户需求不符。数据驱动设计能减少偏见,提高转化率和销售额,是一个迭代过程,不断实验和优化。虽然有些人担忧可能限制创造力,但其实它仍需要创新和妥协。随着业务、用户和技术变化,数据驱动设计提供持续改进的解决方案。
39 0
服务架构中的数据驱动设计
|
19天前
|
网络协议 网络安全 数据安全/隐私保护
KOI websocket服务器转发请求给 orchestra - 什么是 Client Address
KOI websocket服务器转发请求给 orchestra - 什么是 Client Address
15 0
|
19天前
|
Web App开发 JavaScript 前端开发
KOI Orchestra 从微服务提供商获得结果,再发送回 WebSocket 服务器
KOI Orchestra 从微服务提供商获得结果,再发送回 WebSocket 服务器
13 0
|
19天前
|
存储 运维 监控
WebShop WebSocket server 和 WebSocket 客户端的一对多关系维护
WebShop WebSocket server 和 WebSocket 客户端的一对多关系维护
21 0
|
19天前
|
缓存 微服务
01.【微服务架构】服务注册与发现:AP和CP,你选哪个? -- 客户端容错
【5月更文挑战第12天】客户端容错机制确保在服务端或注册中心故障时仍能正确发送请求。当服务端崩溃,由于延迟,客户端一段时间内仍会尝试发送请求。客户端应实施 failover 策略,即检测到调用失败后,切换到其他节点重试,并将故障节点从列表移除。延时通常等于服务端与注册中心心跳间隔加通知时间。若网络问题导致客户端无法访问服务端,客户端应发送心跳以检测服务端状态,成功则恢复,连续失败则视为崩溃。若客户端无法连接注册中心,它应使用本地缓存并考虑退出。
19 1
01.【微服务架构】服务注册与发现:AP和CP,你选哪个? -- 客户端容错
|
19天前
|
Kubernetes Cloud Native 持续交付
探索云原生架构的未来:如何优化资源管理和服务部署
【5月更文挑战第6天】 随着云计算的快速发展,云原生技术已成为企业数字化转型的关键驱动力。此篇文章深入探讨了云原生架构的核心组件及其在资源管理和服务部署方面的优化策略。通过分析容器化、微服务及自动化管理的实践案例,本文旨在为读者提供一套系统的方法论,以利用云原生技术实现更高效、灵活且可靠的IT基础设施。
38 2
|
19天前
|
微服务
01.【微服务架构】服务注册与发现:AP和CP,你选哪个?-- 高可用性
【5月更文挑战第4天】注册中心通过心跳检测服务端状态,当心跳失败时预判服务端崩溃并通知客户端停止使用。心跳机制应对网络不稳定,需平衡重试次数与间隔,避免误判和延迟。即使如此,从服务端宕机到客户端获知仍存在时间差,因此需要客户端具备容错能力。
30 0
|
19天前
|
微服务
01.【微服务架构】服务注册与发现:AP和CP,你选哪个?-- 服务端崩溃检测
【5月更文挑战第3天】保证服务注册与发现的高可用需关注三个方面:服务端崩溃检测、客户端容错和注册中心选型。服务端崩溃时,注册中心通过心跳检测来识别,若心跳中断,立即通知客户端服务不可用,同时持续尝试恢复心跳。若一段时间后仍无法连接,则断定服务端彻底崩溃。这种方法兼顾及时故障通知和防止误判。
36 8
|
19天前
|
微服务 中间件 Nacos
01.【微服务架构】服务注册与发现:AP和CP,你选哪个?-- 面试准备+基本模型
【5月更文挑战第2天】面试准备应涵盖公司所使用的注册中心类型及其优缺点,了解其集群规模、QPS和机器性能。准备故障排查及优化案例。若公司未采用微服务,可熟悉ZooKeeper、Nacos或etcd的基本特性以讨论注册中心概念。面试时,可将话题引导至服务注册与发现,如被问及特定中间件,阐述为何选择它并讨论优缺点。当涉及微服务高可用性时,可强调服务注册与发现的作用。基础模型部分,需解释服务上线和下线流程,提及注册数据和分组功能,并举例说明。最后,简述服务注册与发现的高可用挑战。
35 8
|
3天前
|
敏捷开发 负载均衡 监控
探索微服务架构下的API网关设计与实践
【5月更文挑战第31天】本文将深入剖析微服务架构中的关键组件——API网关,探讨其设计理念、核心功能以及在实际项目中的应用。我们将从API网关的基本概念出发,逐步展开对其路由、负载均衡、认证授权、监控日志等方面的详细讨论,并结合实际案例,分析如何高效地实现和管理一个稳定的API网关。