最后更新:2022-07-17 09:04:11 手机定位技术交流文章
这个系列是基于 GO, micro3的
回顾以前的软件开发问题,预测其未来。改变正在进行中。我们越来越多地走向一个由技术驱动的世界,这是每个业务的核心。在这个时代,保持竞争优势变得越来越困难。当一个组织试图利用低效率平台、过程和结构扩展时,其执行能力可能停滞。十年前,旧科技公司遭受了这种加剧的痛苦,他们中的大多数使用相同的方法来克服这些挑战。
微型服务是创造竞争优势的途径.
微服务是一种软件架构模型,将大型单个应用程序分解为较小可管理的独立服务,这些服务通过语言无关协议(protocol buffers、grpc、micro)进行通信,每个服务都集中在做一件事上。但并不是你必须应用无限制的分区,不是说越小越好。
微服务的概念并不是新;它是一种面向服务的架构的重新设计,但是一个更全面的方法来保持与Unix进程和管道的一致性。
微服务架构的理念:
这些服务是小型的——细粒度的作为一个单一的商业目的,类似于“做一件事,把它做好”的 unix 哲学
组织文化应该包括部署和测试自动化。 这减少了管理和运营的负担
文化和设计原则应该包含失败和错误,类似于反脆弱系统。
随着组织技术的发展和人员的增加,管理单一代码库变得更加困难。 过去,公司曾试图用单一系统扩展产品功能等,但由于系统采用和规模而导致的失败已经变得普遍。
每个团队负责由许多微服务组成的业务功能,这些服务可以独立于其他团队部署。 微服务系统可以实现更快的开发周期、更高的生产率和优越的可扩展系统。
1.扩展开发更容易,团队在不同的业务需要下组织和管理自己的服务。
2.易于理解 - 微型服务规模较小, 通常为100 LOC或少.
3.更频繁地部署新版本的服务-服务可以独立部署、扩展和管理。
4.提高容忍和隔离-焦点分离可以尽量减少一个服务中的问题对另一个服务的影响。
5.提高执行速度-团队通过独立开发、部署和管理微型服务来更快地满足业务需求。
6.可重用服务和快速的原型 — 微服务的根深蒂固的Unix哲学允许您更快速地重用现有服务并构建新功能。
微型是一个微型服务生态系统(不是简单的框架,内置框架用于开发微型服务)。重点提供产品、服务和解决方案,实现现代软件驱动企业创新。计划成为与微型服务有关的任何实际资源(即开发平台,以及提供大量的廉价、内置、完美的API接口),它将设法使公司能够为自己的业务使用这项技术。从早期的原型设计到大规模生产部署。
Go Micro是建立一个框架开发Go Micro服务的早期尝试。此后,我们将把注意力完全转移到微型,这是一个基于云的开发平台,包含服务器、命令行和服务框架(以前是go-micro)。Go Micro已移至asim/go-micro。
它与运行时间无关,可以在任何地方运行。 在裸机、AWS、Google Cloud上,选择运行的最喜欢的容器编译系统(如Mesos或Kubernet)。
软件产业正经历着根本的转变.现有工具和开发实践在这个新时代无法扩展。没有工具让开发人员从单个代码库转换到更有效的设计模式。大多数公司必然会通过单体设计来减少利润,而且必须进行大规模的研发和重建。Netfix 、 Twitter 、 Gilt 和 Hailo 是其中的主要例子。他们最终都建立了自己的微服务平台。
微提供基本的架构,让任何人更容易使用微服务。
Micro默认使用gRPC
微开发是快速的,经过了几个版本,主要是谈论新的版本,以前的概念将很快降低旧版本内容。
Micro(英语:Micro)是一个开放源代码的微服务工具集。Micro提供微服务的构建和管理的核心要求。它包含一系列的库和工具,主要用于开发编程语言Go,但旨在通过HTTP解决其他语言。
GoMicro是一个相互连接的RPC框架,它被用于在Go中建立微服务。它提供了创建、发现和与服务沟通所需的基本功能。任何好的微服务架构的核心始于服务发现、同步和非同步通信。(新版本已经将go-micro和plugins等全整合到一起了)
Micro使团队能够扩展微服务的开发,同时抽象分布式系统和基于云的基础设施的复杂性。它提供了合理的零依赖性默认值的插件和运行时间自由的架构。
GoMicro是微服务开发的核心,但随着服务的编写,下一个问题发生了变化,我如何去询问这些,我如何与他们互动,我怎样以传统的方式服务他们呢?鉴于go-micro使用基于rpc/protobuf的协议,该协议既是插件,也与运行时间无关,有办法解决这个问题,这个方法对于go-micro本身是正确的。这导致了微服务工具包微的创建。Micro 提供 api 门户 、 web 面板 、 cli 、 slack 机器人 、 服务代理等.
go-micro将成为微型服务开发的独立框架。 政府官员开始了整合进程,将所有图书馆移交给go-micro,提供更简单的默认输入体验,并添加更多功能,如登录、跟踪、索引、认证等
微型成为运行时建立微型服务的最简单的方法,并逐渐成为基于云的基于Go的微型服务开发的实际标准。
微工具箱通过 http api 、 browser 、 relax 命令和命令行界面作为交互点。 这些是我们查询和构建应用程序的常见方式,对于我们来说,在运行应用程序时提供真正的实现是很重要的。
微型服务和它们的共同关键概念是相当多的,许多人仍然不知道应该区分什么和区分什么。 以下是这些概念的全面概述,并注意部署概念已经纳入新版本
Micro是一个微服务工具箱,其结构设计为其功能和接口的自给自足,同时提供强大的互连的架构,允许交换从下到上依赖。
Micro致力于解决建筑微服务的基本要求,并希望通过仔细考虑和测量其设计来实现这一点。
GoMicro是一个相互连接的RPC框架,用于在 Go 中编写微服务。它为服务发现、客户端负载平衡、编码、同步和异步通信提供库。
Micro API是一个 API 网关,提供 HTTP 服务并将请求路由到适当的微服务。它充当单个入口点,既可以用作反向代理,也可以将 HTTP 请求转换为 RPC。
微Web是微Web应用程序的Web dashboard和反向代理。我们认为Web应用程序应该作为微型服务,因此应被视为微服务世界中的一等公民。它就像API反向代理,它还包括支持Web接口。
Micro Sidecar提供所有的go-micro功能作为HTTP服务。虽然我们喜欢Go,并认为它是建立微型服务的一个好语言,但你也可能想使用其他语言,因此,Sidecar提供了一种将其他应用程序集成到Micro世界的方法。
Micro CLI是一个直接的命令行接口,用于与您的微服务交互。它还允许您使用Sidecar作为代理,并且您可能不想直接连接到服务注册表。
RPC,REST,原型
为什么是 RPC,为什么不快呢?RPC更适合于服务间通信。或者更具体地说,使用protobuf编码和protobuf IDL定义的API的RPC。此组合允许您创建一个明确定义的API接口和有效的消息编码格式在线。RPC是一个简单的通信协议。
谷歌是protobuf的创建者,内部使用 RPC,最近,gRPC被启动,RPC框架。海洛 也 是 RPC / Protobuf 的 坚定 支持者,并从中受益匪浅,有趣的是,它比系统性能更有利于跨团队开发。选择自己的道路,RPC也开发了一个名为TChannel的框架协议。
个人认为,未来的 API 将使用 RPC 构建,因为它们定义明确的结构化格式、使用高效编码协议(如 protobuf)的倾向以及提供强定义 API 和高性能通信的组合。
HTTP到RPC,API
但实际上,我们还有很长的路要走,从网络上的RPC.虽然在数据中心内部是完美的,但为公共流动提供服务,例如,网站和移动API,则完全是另一回事。面对现实,要摆脱HTTP需要一些时间。这就是 micro 包含API 接口服务和翻译HTTP请求的原因之一。
一个API接口是微服务架构的一个模型,它作为一个进入外部世界的单一入口点,并根据请求向适当的服务提供路径,这允许HTTPAPI本身由不同的微服务组成。
这是一个强大的架构模式。对 API 的某个部分进行一次更改就可能导致整个单体应用崩溃的日子已经一去不复返了。
许多人谈论服务发现,它经常直接去结集,但实际上,它并没有赶上它被广泛应用的时代。更不用说,Kubernet上的许多共同资源,如服务,具有服务发现的属性,更重要的是,我们以后将使用诸如伊西奥这样的高档产品的服务网。
库贝内特斯在容器编译和基于服务平台领域已经成为一个计算力量。随着等D成为他们最喜欢的键值存储,利用 raft consensus构建一个分布式关键值存储器。它已经发展到满足 kubernetes 的规模要求,它在其他开放源代码项目中也很少在现实生活中被测试。
Etcd 也是一个非常标准的二进制数据的 Get/Put/Delete 存储,这意味着我们可以轻松地编码和存储我们的服务元数据而不会出现问题。它对所存储数据的格式没有意见。
官方,它在以前的版本升级中被放弃,使用Konsul等。
微网是一个基于go-micro的全球分布式网络。go-micro是一个Go微服务框架,使开发人员能够快速建立服务,不需要处理分布式系统的复杂性。Go Micro提供了强大的持久的接口,这些接口可插入。但它也有一个声音默认值。这使得GoMicro服务可以在任何地方建立并部署,零代码更改。
微网使用五个核心术语:注册、传输、代理、客户和服务器(类似于grpc调用,只是规模更大)。我们的默认实现可以在go-micro框架的每个包中找到。社区支持的插件位于go-plugins库中。(新版本将go-micro和go-plugins合并)
微型“网络”是一个过载的术语,全球网络,提供服务并互相交流,也指由平行节点组成的支助系统,这些同行节点连接到每个节点并建立服务通信路径。该网络抽象了在任何云或机器上大规模分布式系统通信的低层次细节。让任何人共同建立一个服务,没有必要考虑它们在何处运作。这基本上实现了资源的大规模共享,更重要的是微服务。
有四个基本概念使微网络成为可能。
隧道- 点对点隧道
代理人-透明rpc代理人
路由器-路由器集成和广告
网络-基于上述三个的多云网络
这些组件中的每一个都与任何其他Go Micro组件一样 - 可插拔,具有开箱即用的默认实现来开始。在我们的案例中,微网络重要的是默认设置在全球范围内大规模运行。
(事实上,我们大部分时间都在自己的本地网络上运行服务,很少像全球网络那样大。
从高层次来看,微网络是一个跨越互联网的覆盖网络。所有微网络节点之间保持安全隧道连接,以实现网络中运行的服务之间的安全通信。Go Micro 使用 QUIC 协议和自定义会话管理提供默认隧道实现。
QUIC的选择是因为它提供了一些优秀的功能,特别是在处理高延迟网络时,这是一个在大型分布式网络中运行的服务处理中的重要特征。QUIC在UDP上运行,但通过添加一些基于连接的语义,它支持可靠的数据包传输。QUIC还支持多个流量,无需线头堵塞,它被设计用于与机器加密相结合。最后,QUIC在用户空间中运行,而不是传统的系统的核心空间,因此它也可以提供性能和额外的安全。
微隧道使用quic-go,这是最完整的QuiC Go实现,可以在微网的开端找到。 quic-go 是一项正在进行的工作,它偶尔会中断,但仍愿意支付早 adopter的成本,因为我们相信 QUIC将在未来成为事实上标准的互联网通讯协议,支持大规模网络,例如微网。
隧道接口源码:
在Go Micro中,保持一个与分布式系统的开发相一致的共同界面,同时在较低层次干预解决一些详细问题。
通道很像地址,提供一种用于分开隧道中的不同消息流的方法.听者在指定的频道中听,当客户端拨入频道时,返回唯一的对话.这个对话被用来在同一隧道的同僚之间进行交流。Go Micro隧道也提供了不同的通信语义。你可以选择使用单播或多播。
微路由器是微网络的重要组成部分.它提供了一个网络路由飞机.如果没有路由器,你不知道该去哪里发送消息。它建立基于本地服务注册表(Go Micro的一个组件)的路由表。路由表维护在本地网络上可用的服务路由.通过隧道,它还可以处理来自任何其他数据中心或网络的信息,默认启用全球路由.
默认路由表实现使用简单的 Go in memory 映射,但与 Go Micro 中的所有东西一样,路由器和路由表都是可插拔的。
源码:
当路由器启动时,它将自动为其本地笔记本表创建一个观察员.当服务创建、更新或删除时,微型注册处将发布一个事件.路由器处理这些事件,然后将该操作应用于其路由表。路由器本身通知路由表事件,你可以把它看作注册表的缩减版本,仅与请求路由有关,因为登记册提供了更多的功能信息,例如, api端点。
这些路由作为事件被传输到其他路由器在本地和全球网络上,并由每个路由器应用到其自己的路由表,维护全球网络路由平面。
这里的主要关切是首先以服务名称进行路由,如果你需要通过远程终端或不同的网络,然后寻找它的本地地址或门户.如果你想知道要使用什么样的链接,例如,它可以通过隧道、Cloudflare Argo隧道或其他网络实现进行路由。最重要的是,指标,这就是通往那个节点的路费。有事会有很多路由,希望采用成本最优的路由以确保最低延迟。这并不总是意味着您的请求被发送到本地网络!想象一下在本地网络上运行的服务过载.无论服务在哪里运行,我们总是选择最低成本的路线.
我们讨论了隧道--如何从点到点传递消息,以及路由--详细说明如何找到服务的位置,但问题是服务如何使用它。为此,我们需要一个代理人。
在构建微网络时,我们构建的东西对我们来说很重要,它是微原生的并且能够理解我们的路由协议。构建另一个基于 VPN 或 IP 的网络解决方案不是我们的目标。相反,我们希望促进服务之间的通信。
当服务需要与网络中的其他服务进行通信时,它使用微代理。
代理是基于GoMicroClient和Server接口的本地RPC代理实现。它包含了我们服务的通讯核心模式,它还提供基于服务名称和端点的请求转移机制。此外,它也可以作为异步消息交换,因为Go Micro支持请求/响应和发布/订阅通讯。这是原始的GoMicro,它是请求路由的强有力的构建块.
接口本身是简单的,包涵了代理的复杂性。
代理接收RPC请求并将它们调到终端.它向路由器询问服务的位置(必要时缓冲),根据Link路由表中的字段,决定是否通过全球网络通过隧道或本地发送请求。该Link字段的值是“local"(对于本地服务)或者“network"该服务只能通过网络访问。
与其他所有事情一样,代理是我们独立构建的,它可以在数据中心的服务之间工作,但在隧道和路由器中使用时,它也可以在多个服务之间工作。
最后我们到达了阻力水平。
网络节点是连接所有核心组件的魔法。使建立真正的全球服务网络.在创建网络接口时,要使它符合我们现有的假设和了解GoMicro和分布式系统开发的重要性。我们真正想接受框架的现有接口,设计一些服务对称性问题。
我们得到的是与micro.Service接口本身非常相似的东西
aNetwork有名称、客户端和服务器,非常类似于服务,因此,它提供了一种类似的通信方法。这意味着我们可以重用大量的现有代码库,但它也走得更远。A直接在接口中Network包含 a 的概念Node,它有一个等价点,可以属于同一个网络或其他网络。这意味着网络是点到点的,服务主要集中在客户/服务器上。开发人员每天都关注建筑服务,但当这些服务用于全球通信时,它们需要运行在相同的网络上。
我们的网络有能力充当为其他人路由的对等点,但也可以自己提供某种服务。在这种情况下,它主要是路由相关信息。
该网络有一个同等节点的列表,可以与之交谈。在默认实现的情况下,同等列表来自同名(网络本身的名称)的其他网络节点的注册表。当一个节点启动时,它创建了隧道,分析了节点,然后连接到它们,“连接”到网络上。一旦他们通过两个多播对话连接节点,一个用于对等公告,另一个用于路由公告。随着这些传播,网络开始收集相同的路由信息,建立一个完整的网格,允许服务从任何节点转到另一个节点。
节点维护保持稳态,定期通知完整的路由表,并在事件发生时更新它们。我们的核心网络节点使用多个分析器互相搜索.包含DNS和本地注册表。对加入我们的网络的另一方,我们已配置它们使用http分析器,分析器以Cloudflare DNS分配为地理指导,它将平衡全球负荷到最局部地区.他们从那里提取了一个节点列表,并将其连接到最低索引的节点。然后他们重复了上面的同样的舞蹈,继续发展网络并参与服务路由.
每个节点根据其接收到的对等消息维护自己的网络图。对等消息包含最多 3 跳的每个对等点的图表,这使每个节点都能够构建网络的本地视图。对等点忽略任何超过 3 跳半径的东西。这是为了避免潜在的性能问题。
我们 提到 了 一些 关于 柜台 和 路线 的 资料 。那么网络节点实际交换的信息是什么?首先,网络嵌入路由器接口,通过这个接口,它将局部路由到其他网络节点。然后这些路线在整个网络中传播。就像互联网一样。节点本身从它的另一端接收了路由信号,通知的更改将应用于其自己的路由表。消息类型是请求请求路由和广告广播更新。
网络节点在启动时发送“连接”消息,在退出时发送“关闭”消息。 在他们一生中,他们会定期广播“正确的”消息,以便其他人能够找到它们,并建立网络拓扑。
当网络创建和合并时,该服务能够通过它发送消息。当网络服务需要与其他网络服务进行通信时,它向网络节点发送请求。微网络节点嵌入了微代理,因此,可以通过网络或本地发送请求,如果它认为在搜索路由表中的路由后更适当地检索找到的索引。
这个整体构成了我们的微服务网络。
开发人员使用GoMicro框架来编写他们的Go代码,一旦他们准备好,他们就可以直接从他们的笔记本电脑或微网络节点运行的任何地方在网络上提供他们的服务(就类似于自己写的服务可以使用grpc等进行远程调用,只是这里范围更大,这是一个全球微服务网络)
一个简单的书面服务go-micro的例子:
启动服务后,它会自动向服务注册中心注册,并且网络上的每个人都可以立即访问以进行消费和协作。所有这些对开发人员来说都是完全透明的。无需处理低级分布式系统垃圾!
或者你也可以将服务的代码clone下来,运行在你的局域网,然后类似grpc去调用即可,只不过这底层的调用被micro抽象
又名micro3
微服务开发平台,云原生开发平台,是一个 API 驱动开发的平台。
Micro已经从一个Go框架转移到一个独立的服务器和支持平台
一种在云端及其他地方构建分布式系统的简单得多的方法,无需管理基础设施。M3O(源自单词M[icr]o)是多年分布式系统开发经验的结晶。
所有致力于软件开发的尝试都遭到了新的云计算时代的阻挠
Micro 最初是一个用于微服务开发的 Go 框架。以开发人员为中心解决分布式系统开发问题。它采取了以尽可能最小的方式解决这个问题的方法。但现在,我们发现自己在不断发展并继续成为运行时和平台。
M3O 是一个微服务开发平台。一个完全托管的云平台,开发人员无需接触基础设施,让他们重新专注于产品和服务开发。每家成功的科技公司最保守的秘密现在正向全世界开放,作为一个定价简单的托管平台。
目标 是 集中 注意 :
1.开发者生产力-使开发者集中于建筑服务
2.合作与重用-该平台是为了分享团队间和团队间的服务
3.所有服务-平台上的所有应用程序都是以微服务为基础的
4.发展速度-我们正在建立一个环境,使你能够快速地向前迈进
Micro是开发微型服务的工具箱,结合API开关、Web Widget和Cli来与使用Go RPC框架构建的服务交互
M3O提供三个内置环境:本地、开发和平台。
1.Local-Micro在您的本地机器上运行
2.Dev - 在云中自由开发环境
平台3 - 安全、可扩展和支持的生产环境,有收费
像这样与环境交互。
本地环境就是这样,本地笔记本电脑。这是发展开始的地方,这通常需要你运行各种疯狂的基础设施。微型集中于提供嵌入式抽象作为gRPC服务,因此,服务只要求gRPC直接与Micro对话,微隐藏用户细节。在本地,这意味着我们正在利用我们所能做的,例如,mdns,文件存储等。
从一开始就变得非常简单,只要执行一个命令。
“开发”环境是提供 Micro 3.0 即服务的免费云托管环境。那里有一些很棒的开源工具,开发环境使每个人都能够使用与在云中进行本地开发相同的工具,在几分钟内启动并运行。
如果 env 设置为 "dev", 它可以作为本地使用.
如果使用的是开发环境,可以在m3o.dev上查找更多详细信息
平台环境是安全、可扩展和支持的生产环境,它可以运行面向客户服务和产品。这是一个付费层,它的资源限制是开发者资源限制的两倍,包括slack和电子邮件支持和SLA。你可以把它看作你在任何工作场所都熟悉的一个生产平台。
我们在 Local、Dev 和 Platform 方面的目标是调用我们都知道并期望作为真正产品的工作流程。这些是完全独立的环境,它们的管理方式与 M3O 完全相同。
随着kubernetes等系统出现和云层的推进,你可以看到,确实需要转向分享资源。云并不便宜,我们也不强制运行单独的 kubernetes 集群(最好还是使用kubernetes)。micro使用与 kubernetes 相同的逻辑来构建多租户,称为命名空间。
微观地映射出同样的经验,因此,本地开发者可以获得命名空间的基本形式,但大多数情况下,在生产中使用命名空间的库贝内特,以及大量用于认证、存储、配置、事件流等的自定义写入隔离机制,“Micro 3.0”可以用于管理多个租户。
每个语句都有一个名称空间,名称空间在每个子系统中都有自己的独立用户群和资源。 当您作为用户或服务发出任何请求时,将通过 JWT许可证,以便下层系统可以调用到适当的资源。
注册开发环境后,您将设置命名空间。 您可以使用该命令获取它(登录帐户)
当您使用任何类型的 CLI 命令时,你的命名空间和身份验证令牌会自动注入到请求中,包括刷新这些令牌。在 Micro 上运行的任何服务都会发生同样的情况。
此外,每个命名空间都有自己的自定义域,所以 foobar命名空间变成了 foobar.m3o。 例如, dev服务 helloworld提供了 Foobar.m3o.dev/helloworld的路径
微型基于对现有工具的不满。作者希望按顺序运行源代码.使用希罗库,我们能做到这一点。但它离我们太远了。早在2010年,希罗库专注于单人游戏《铁轨》开发。作者认为希罗库偷走了太多,AWS已经给予过多的反馈。我们需要两者之间的东西。我们不需要依靠虚拟机器或容器,但另一方面,它并不局限于单体发展。
Micro可以从本地目录或存储在Github、Gitlab或bitbucket上的存储库中检索源代码。在一个命令中,它将从相关位置上上传或提取,把它装进容器里,然后运行,只用一个命令运行的源代码。不再需要处理管道,不再对容器和容器注册表进行攻击。
一个真正缺少的新Paas热波是模型的开发。
微型一直专注于分布式系统开发或微型服务实践。 将大型单体应用分解为较小的独立服务的想法可以很好地完成一件事。
服务的概念,它包含一个客户端和服务器,用于处理请求和对其他服务进行查询。micro专注于围绕 API 定义的 protobuf 进行标准化,并使用 gRPC 进行网络分层。
每个微型开发平台都使用一个单一语言,例如, 网络, 移动, 等等.云也不例外。Go for Cloud的微型支持,但他认为需要一个生态系统来消费Go服务,它也可以扩展到 python 、 java 、 Ruby 、rust 或 javascript 不能使用的地方。因为Micro的接口是gRPC,因此我们通过代码生成gRPC客户端,允许任何语言使用Micro服务器。(底层就是protocol buffers使用grpc方式生成服务器的骨架和客户端的存根,服务器和客户端分别使用)
使用 gRPC,跨语言变得简单,有一个内部服务框架,你可以用Go非常优雅地写代码,但gRPC允许我们减少表面区域的范围,为支持的强型客户提供不同的开发模型,可能更大的空间以一种框架无法实现的方式推动微型服务被广泛采用。
micro还包括 grpc-web生成的客户端,允许前端快速和容易使用类型的JavaScript客户端使用与后端相同的开发。我们已经看到grpc-web在每个公司中逐渐被采用,并认为这也可能很快扩展到公共领域。
查看生成客户端的Micro/client/sdk目录,这些目录将在不久的将来向各自的包管理员发布。
Micro旨在简化微服务开发,提高后端开发人员的生产力,除了能够使用gRPC来使用这些服务之外,我们认为,世界仍然对基于HTTP/JSON的API非常感兴趣,因此,Micro包含了API接口,它可以自动转换http/json到grpc请求。这意味着任何人都可以在云中建立API优先服务,而无需做任何事情。
这是一个简单的例子。
假设你用下面的原型程序在后端写好世界
随后,它作为M3O平台的“你好世界”服务发布。 您可以立即使用$ namespace.m3o。 表格 dev/helloworld/message访问它
我们使用路径分析来映射到gRPC的http请求。因此 / [ 服务 ] / [ 方法 ] 成为 [ 服务 " 方法 " 。如果您的微服务名因某种原因不与proto匹配(您有多个proto服务),所以它的工作方式会略有不同,例如,您的服务名称是 foobar,然后端口被更改为 / foobar/helloworld/message。
go-micro已经丢弃,只开发为go-micro2版本,没有正式维护,只在作者的个人Github帐户上,现在使用micro3
云源基本上是一个描述性的术语,它可能听起来像一个流行的描述在云中运行的东西的术语。事实上,这只是意味着,该软件是建立在云中运行的。这与我们以前的建筑方式有什么区别?云的背后的想法是,它们是短期的,可扩展的,并且任何东西都可以通过API访问。(云计算:云上,利用云计算提供的基本计算和存储能力,云原生:云里,建立在云环境中运行的软件应用程序)
我们期望在云上运行的服务大多是无国籍的,利用外部服务来维持,它们以名称而不是IP地址识别,他们自己提供了一个可以由多个客户使用的API,例如, 网络 、 移动和Cli或其他服务.
云原生应用程序是水平可扩展的,并且在域边界内运行,将它们划分为单独的应用程序,这些应用程序通过其 API 在网络上进行通信,而不是作为一个单一的实体。云服务需要一种完全不同的软件创建方法
本文由 在线网速测试 整理编辑,转载请注明出处。