微服务架构是什么?

微服务架构是一项在云中部署应用和服务的新技术。

大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。

微服务架构相关介绍：

微服务可以在“自己的程序”中运行，并通过“轻量级设备与>

在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。

微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。

如果你阅读了Fowler的整篇文章，你会发现，其中的指导建议是非常实用的。在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越难以符合规定原则。

服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。然而，利弊之间的权衡过程是非常复杂的，我们要在配置和资金模型的基础上考虑到基础设施的成本问题。

Tars。
根据查询CSDN网可知，Tars是一个支持多语言内嵌服务治理功能的框槛，能与 DevOps 比较好的协同开发。提供了包含开发、运维、以及测试的一整套解决方案。通过Tars可快速用微服务的方式构建自己高可用的分布式应用，并实现完整有效的服务治理。
Tars是一个跨平台、跨语言的软件运行环境，是基于service mesh设计理念实现的开发框架。Tars集可扩展协议编解码、高性能 RPC 通信框架、名字路由与发现、发布监控、日志统计、配置管理等于一体。

1 Linux 服务器安装宝塔面板

2使用ssh root@ip 的方式远程连接

3安装Docker ,参考: >

什么是docker

Docker 最初是 dotCloud 公司创始人 Solomon Hykes 在法国期间发起的一个公司内部项目，它是基于 dotCloud 公司多年云服务技术的一次革新，并于 2013 年 3 月以 Apache 20 授权协议开源，主要项目代码在 GitHub 上进行维护。Docker 项目后来还加入了 Linux 基金会，并成立推动 开放容器联盟（OCI）。

Docker 使用 Google 公司推出的 Go 语言 进行开发实现，基于 Linux 内核的 cgroup，namespace，以及 AUFS 类的 Union FS 等技术，对进程进行封装隔离，属于 *** 作系统层面的虚拟化技术。由于隔离的进程独立于宿主和其它的隔离的进程，因此也称其为容器。最初实现是基于 LXC，从 07 版本以后开始去除 LXC，转而使用自行开发的 libcontainer，从 111 开始，则进一步演进为使用 runC 和 containerd。

Docker 在容器的基础上，进行了进一步的封装，从文件系统、网络互联到进程隔离等等，极大的简化了容器的创建和维护。使得 Docker 技术比虚拟机技术更为轻便、快捷。

下面的比较了 Docker 和传统虚拟化方式的不同之处。传统虚拟机技术是虚拟出一套硬件后，在其上运行一个完整 *** 作系统，在该系统上再运行所需应用进程；而容器内的应用进程直接运行于宿主的内核，容器内没有自己的内核，而且也没有进行硬件虚拟。因此容器要比传统虚拟机更为轻便。



传统虚拟化



Docker

为什么要用docker

对开发和运维（DevOps）人员来说，最希望的就是一次创建或配置，可以在任意地方正常运行。

使用 Docker 可以通过定制应用镜像来实现持续集成、持续交付、部署。开发人员可以通过 Dockerfile 来进行镜像构建，并结合 持续集成(Continuous Integration) 系统进行集成测试，而运维人员则可以直接在生产环境中快速部署该镜像，甚至结合 持续部署(Continuous Delivery/Deployment) 系统进行自动部署。

而且使用 Dockerfile 使镜像构建透明化，不仅仅开发团队可以理解应用运行环境，也方便运维团队理解应用运行所需条件，帮助更好的生产环境中部署该镜像。

特性容器虚拟机 启动秒级分钟级 硬盘使用一般为MB一般为GB 性能接近原生弱于 系统支持量单机支持上千个容器一般几十个

基本概念

我们都知道， *** 作系统分为内核和用户空间。对于 Linux 而言，内核启动后，会挂载 root 文件系统为其提供用户空间支持。而 Docker 镜像（Image），就相当于是一个 root 文件系统。比如官方镜像 ubuntu:1804 就包含了完整的一套 Ubuntu 1804 最小系统的 root 文件系统。

Docker 镜像是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（如匿名卷、环境变量、用户等）。镜像不包含任何动态数据，其内容在构建之后也不会被改变。

镜像（Image）和容器（Container）的关系，就像是面向对象程序设计中的 类 和 实例 一样，镜像是静态的定义，容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。

前面讲过镜像使用的是分层存储，容器也是如此。每一个容器运行时，是以镜像为基础层，在其上创建一个当前容器的存储层，我们可以称这个为容器运行时读写而准备的存储层为容器存储层。

按照 Docker 最佳实践的要求，容器不应该向其存储层内写入任何数据，容器存储层要保持无状态化。所有的文件写入 *** 作，都应该使用 数据卷（Volume）、或者绑定宿主目录，在这些位置的读写会跳过容器存储层，直接对宿主（或网络存储）发生读写，其性能和稳定性更高。

数据卷的生存周期独立于容器，容器消亡，数据卷不会消亡。因此，使用数据卷后，容器删除或者重新运行之后，数据却不会丢失。

镜像构建完成后，可以很容易的在当前宿主机上运行，但是，如果需要在其它服务器上使用这个镜像，我们就需要一个集中的存储、分发镜像的服务，Docker Registry 就是这样的服务。

一个 Docker Registry 中可以包含多个仓库（Repository）；每个仓库可以包含多个标签（Tag）；每个标签对应一个镜像。

通常，一个仓库会包含同一个软件不同版本的镜像，而标签就常用于对应该软件的各个版本。我们可以通过 <仓库名>:<标签> 的格式来指定具体是这个软件哪个版本的镜像。如果不给出标签，将以 latest 作为默认标签。

Centos安装docker18

常用的docker命令

常用的docker镜像

redis

mysql

1、微服务(MicroservicesArchitecture)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

2、微服务是指开发一个单个小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。

3、微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；如果你需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务。

tomcat 启动maven项目失败
maven的日志在哪里看_听说你还不会在服务器上部署项目？看这一篇文章就够了

weixin_39664995
关注
1点赞·1792人阅读
作为一名资深(fu xiu)的程序猿来说，一直不想向IDEA低头可能是我对MyEclipse最大的尊重。最近利用SSM框架搭建了一个项目后台。但是由于开发人员并不能处于同一个局域网中，于是将后台需要部署到公网服务器中。但是与普通的javaweb项目不同的是该项目是一个基于maven的多模块工程。其实刚开始笔者一直在担心不知如何部署，在网上搜到的资料也是零星半点。通过网上的一些思路，加上自己半天的摸索，终于将后台成功部署到服务器上。下面就具体讲解一下如何部署maven多模块工程到公网服务器上。PS:笔者服务器选用某云服务器(服务器只要是公网运行的就可以了！)
1、对maven项目进行打包，文件格式为war包
我们在使用SSM框架进行构建项目的时候， 父工程的打包方式是pom，common工程的打包方式是jar，主要的项目工程是我们的聚合工程，打包方式是pom， 聚合工程中又包括dao、pojo、interface、service、web工程，其中前四个打包方式都为jar，web工程的打包方式为war，那么我们的思路就很清晰了——就是将web工程打包出来。下图给出项目文件的整体架构图。
项目结构图
对父工程、common工程、项目工程文件进行安装，安装方法就是对工程进行右键---> Run as ---> Maven install， *** 作过程如下图所示：
安装maven项目
如果项目没有同步更新的话，在这一步可以对项目行update，具体 *** 作过程可以见下图。
更新maven项目
安装成功后在console框中可以看到安装成功之后的war包的路径，如下图所示。
war包所在文件夹
从计算机中打开这个路径，就会看到一个web工程的war包，我们可以记住这个路径，然后登陆上我们的云服务器。项目需要部署到tomcat容器中，因此需要在服务器上安装tomcat容器，运行tomcat的前提还是需要保证服务器上具有jdk环境。因此还需要在服务器上安装jdk，安装jdk以及tomcat容器的步骤实质非常简单，配置环境变量的步骤稍稍有些复杂，如果有不清楚的读者还不清楚怎么安装，可以自行百度或者评论留言，如果有必要我也会一步一步地将安装过程整理成一个帖子发出来。
打包后的war文件
在此假设我们的服务器已经有了jdk环境以及tomcat容器。将我们上步的war包通过文件上传工具上传到我们的服务器环境，然后进入服务器中的tomcat安装包中。
tomcat安装包
将上传到服务器的war包复制到tomcat的webapps目录下(使用cp命令进行复制)，复制之后的结果如下图所示：
复制成功自动解压文件
我们退回到启动bin目录下，也可以直接输入命令(这种需要我们对tomcat的安装包目录比较熟悉后使用)，启动之后我们可以查看tomcat的启动日志
//启动tomcat的命令 进入bin目录下 运行startupsh文件(假设我们目前在webapps目录下)/bin/startupsh//查看tomcat启动日志的命令(假设在webapps目录下)tail -f /logs/catalinaout
登录后复制
看到如下的结果说明我们的tomcat启动成功：
tomcat启动成功
在浏览器中验证服务是否正常启动后台，在地址栏中输"公网ip：端口号(默认8080，可以自行设置端口80)/ 工程名/ controller文件下请求的路径"，成功如下图所示。写到这里，说明我们的后台服务已经能够正常启动，相对于一个前后端分离的项目，日后我们只需对后台进行维护和添加相应的服务，前端可以根据自己的需求进行请求服务，不受距离限制，保证网络即可。在整个配置过程中笔者还遇到一些其他的问题，但都不是很难受的问题，只要我们认真看启动日志，就能够解决一多半的问题。在此期间我遇到一个无法连接jdbc的问题，问题描述很清晰："can‘t not connect the jdbc"。遇到这种问题首先很容易想到是不是网络问题，但是对于本项目而言，数据库是使用的公网的oracle数据库，同一个服务器上的应该不存在这种问题，想想既然会在同一台机器那么我们是不是可以使用localhost或者127001这种连接地址进行连接数据库(因为数据库相对于服务器来说应该说是本地环境)，但是试了一下发现还是不可以，但是我觉得我想的道理应该没错，可能受于云服务器的安全限制。于是我又改回来原来的ip。使用本地服务器连接公网数据库，发现还是同样的错误，于是我就想到了公网的数据库很有可能没有跑起来，再然后我去服务器上查看oracle的进程以及端口都没有开启监听，使用navicat for oracle连接数据库都显示没有开启监听问题，这种更加确定了问题的所在--数据库没有启动。于是在服务器上又开始开启数据库，由于第一次在云服务器上 *** 作oracle数据库显然也是遇到了许多困难，对一些命令不熟悉不知道如何开启监听，也害怕哪个命令会搞坏这个东西，但最终还是摸索开启了数据库(如果大家这部分还有疑问的话可以评论留言，我有空还是会把这部分的经验步骤写出来，虽然不可能面面俱到的讲解，但起码我们有了解决问题的能力！)，最终数据库连接成功。至此mavne多模块项目也就成功部署到了云服务器上！
浏览器验证成功
如果这篇经验贴对您有帮助或者有点启发，那么笔者写这么多的内容也算没有白费，请您一定不吝点赞或者评论，有问题我们可以一起解决！
maven的日志在哪里看
myeclipse部署tomcat
tomcat 启动maven项目失败
tomcat 部署war 访问路径去掉war包名
微服务项目怎么部署到服务器上
怎么把部署到服务器上
二手进口功放机，正品保证！
精选推荐
广告

如何将项目部署到服务器上(全套教程)
4934阅读·4评论·5点赞
2022年7月31日
JavaWeb - Maven基础
86阅读·0评论·1点赞
2019年10月8日
linux 执行maven项目jar包，并指定日志路径
597阅读·0评论·0点赞
2022年10月2日
maven项目打包部署到虚拟机测试和生产环境上及查看日志 *** 作
2826阅读·0评论·0点赞
2018年4月27日
Maven项目配置Log日志
2551阅读·0评论·1点赞
2019年8月8日
maven的日志在哪里看_SpringBoot统一日志处理原理
1541阅读·0评论·0点赞
2020年11月20日
功放机什么牌子好 功放机选购攻略分享

精选推荐
广告
maven的log日志文件的配置
10W阅读·6评论·1点赞
2019年4月7日
Maven错误日志：Maven简介、使用过程、注意事项、错误解决方案
232阅读·0评论·0点赞
2022年5月4日
Maven 项目添加Log日志
5225阅读·0评论·1点赞
2018年11月29日
maven 调试日志的命令
199阅读·0评论·1点赞
2022年9月6日
maven的日志在哪里看_日志管理领域研究现状(2)
256阅读·0评论·0点赞
2020年11月5日
maven的日志在哪里看_搭建私有Sentry日志收集系统并集成到springboot
182阅读·0评论·0点赞
2020年10月18日
idea maven项目日志配置
3714阅读·0评论·0点赞
2017年7月14日
logback修改日志内容_巧用maven profile动态修改logback日志目录
323阅读·0评论·0点赞
2020年11月28日
idea中查看maven信息
2252阅读·0评论·0点赞
2021年8月27日
log4j配置
92阅读·0评论·0点赞
2020年9月15日
maven工程引入日志
398阅读·0评论·0点赞
2021年7月5日
eclipse中maven项目配置日志输出
8985阅读·0评论·3点赞
2016年11月22日
maven插件日志保存处理
650阅读·0评论·1点赞
2019年2月20日
maven学习日志之一 Maven概念
1302阅读·0评论·0点赞
2016年8月17日
去首页
看看更多热门内容

微服务¹架构的目标是帮助工程团队更快，更安全，更高质量地交付产品。解耦服务允许团队快速迭代，对系统的其余部分影响最小。

在Medium，我们的技术堆栈始于2012年的单片Nodejs应用程序。我们已经构建了几个卫星服务，但我们还没有制定一个系统地采用微服务架构的策略。随着系统变得越来越复杂并且团队不断发展，我们在2018年初转向了微服务架构。在这篇文章中，我们希望分享我们有效地做到这一点并避免微服务综合症的经验。

首先，让我们花一点时间来思考微服务架构是什么，不是什么。 “微服务”是那些过载和混乱的软件工程趋势之一。这就是我们在Medium认为它是什么：

该定义包括三个微服务设计原则：

Three Principles of Modeling Microservices

当我们对微服务进行建模时，我们应该遵守所有三个设计原则。这是实现微服务架构全部潜力的唯一途径。错过任何一个都会成为反模式。

没有一个目的，每个微服务最终会做太多事情，成长为多个“单片”服务。我们不会从微服务架构中获得全部好处，我们也会支付运营成本。

如果没有松散耦合，对一个服务的更改会影响其他服务，因此我们无法快速安全地发布更改，这是微服务架构的核心优势。更重要的是，紧密耦合引起的问题可能是灾难性的，例如数据不一致甚至数据丢失。

如果没有高凝聚力，我们将最终得到一个分布式单片系统 - 一组混乱的服务，必须同时进行更改和部署才能构建单一功能。由于多个服务协调的复杂性和成本（有时跨多个团队），分布式单片系统通常比集中式单片系统差得多。

与此同时，了解 微服务不是什么 很重要：

在Medium，我们总是在做出重大产品或工程决策时会问“为什么现在？”这个问题。 “为什么？”是一个显而易见的问题，但它假设我们拥有无限的人，时间和资源，这是一个危险的假设。当你想到“为什么现在？”时，你突然有了更多的限制 - 对当前工作的影响，机会成本，分心的开销等等。这个问题有助于我们更好地优先考虑。

我们现在需要采用微服务的原因是我们的Nodejs单片应用程序已经成为多个方面的瓶颈。

首先，最紧迫和最重要的瓶颈是其性能。

某些计算量很大且I / O很重的任务不适合Nodejs我们一直在逐步改进整体应用程序，但事实证明它是无效的。它的低劣性能使我们无法提供更好的产品而不会使已经非常慢的应用程序变慢。

其次，整体应用程序的一个重要且有点紧迫的瓶颈是它会减慢产品开发速度。

由于所有工程师都在单个应用程序中构建功能，因此它们通常紧密耦合。我们无法灵活地改变系统的一部分，因为它也可能影响其他部分。我们也害怕做出重大改变，因为影响太大，有时难以预测。整个应用程序作为一个整体进行部署，因此如果由于一次错误提交导致部署停滞，那么所有其他更改（即使它们完全正常工作）也无法完成。相比之下，微服务架构允许团队更快地发货，学习和迭代。他们可以专注于他们正在构建的功能，这些功能与复杂系统的其余部分分离。更改可以更快地进入生产。他们可以灵活地安全地尝试重大变革。

在我们新的微服务架构中，更改会在一小时内完成生产，工程师不必担心它会如何影响系统的其他部分。该团队还 探索 了在开发中安全使用生产数据的方法²多年来一直是白日梦。随着我们的工程团队的发展，所有这些都非常重要。

第三，单一应用程序使得难以为特定任务扩展系统或隔离不同类型任务的资源问题。

使用单一的单一应用程序，我们必须扩展和缩小整个系统，以满足更多资源需求的任务，即使这意味着系统过度配置用于其他更简单的任务。为了缓解这些问题，我们对不同类型的请求进行分片，以分离Nodejs进程。它们在一定程度上起作用，但不会扩展，因为这些微单一版本的单片服务是紧密耦合的。

最后但同样重要的是，一个重要且即将成为紧迫的瓶颈是它阻止我们尝试新技术。微服务架构的一个主要优点是每个服务都可以使用不同的技术堆栈构建，并与不同的技术集成。这使我们能够选择最适合工作的工具，更重要的是，我们可以快速安全地完成工作。

采用微服务架构并非易事。它可能会出错，实际上会损害工程生产力。在本节中，我们将分享七个在采用早期阶段帮助我们的策略：

有人可能会认为采用新的服务器架构意味着产品开发的长时间停顿以及对所有内容的大量重写。这是错误的做法。我们永远不应该为了建立新的服务而建立新的服务。每次我们建立新服务或采用新技术时，都必须具有明确的产品价值和/或工程价值。

产品价值应以我们可以为用户提供的利益为代表。与在单片Nodejs应用程序中构建值相比，需要一项新服务来提供值或使其更快地交付值。工程价值应该使工程团队更好，更快。

如果构建新服务没有产品价值或工程价值，我们将其留在单一的应用程序中。如果十年内Medium仍然有一个支持某些表面的单片Nodejs应用程序，那就完全没了问题。从单一应用程序开始实际上有助于我们战略性地对微服务进行建模。

建立具有明确价值的新服务

有人可能会认为采用新的服务器架构意味着产品开发的长时间停顿以及对所有内容的大量重写。这是错误的做法。我们永远不应该为了建立新的服务而建立新的服务。每次我们建立新服务或采用新技术时，都必须具有明确的产品价值和/或工程价值。

产品价值应以我们可以为用户提供的利益为代表。与在单片Nodejs应用程序中构建值相比，需要一项新服务来提供值或使其更快地交付值。工程价值应该使工程团队更好，更快。

如果构建新服务没有产品价值或工程价值，我们将其留在单一的应用程序中。如果十年内Medium仍然有一个支持某些表面的单片Nodejs应用程序，那就完全没了问题。从单一应用程序开始实际上有助于我们战略性地对微服务进行建模。

单片持久存储被认为是有害的

建模微服务的很大一部分是对其持久数据存储（例如，数据库）进行建模。跨服务共享持久数据存储通常似乎是将微服务集成在一起的最简单方法，然而，它实际上是有害的，我们应该不惜一切代价避免它。这就是原因。

首先，持久数据存储是关于实现细节的。 跨服务共享数据存储会将一个服务的实现细节暴露给整个系统。如果该服务更改了数据的格式，或者添加了缓存层，或者切换到不同类型的数据库，则还必须相应地更改许多其他服务。 这违反了松散耦合的原则。

其次，持久数据存储不是服务行为，即如何修改，解释和使用数据 。如果我们跨服务共享数据存储，则意味着其他服务也必须复制服务行为。 这违反了高内聚的原则 - 给定域中的行为泄露给多个服务。如果我们修改一个行为，我们将不得不一起修改所有这些服务。

在微服务架构中，只有一个服务应该负责特定类型的数据。所有其他服务应该通过负责服务的API请求数据，或者保留数据的 只读非规范（可能具体化）副本 。

这可能听起来很抽象，所以这是一个具体的例子。假设我们正在构建一个新的推荐服务，它需要来自规范帖子表的一些数据，目前在AWS DynamoDB中。我们可以通过两种方式之一为新推荐服务提供发布数据。

在单片存储模型中，推荐服务可以直接访问单片应用程序所执行的相同持久存储。这是一个坏主意，因为：

缓存可能很棘手。 如果推荐服务与单一应用程序共享相同的缓存，我们也必须在推荐服务中复制缓存实现细节;如果推荐服务使用自己的缓存，当单片应用更新帖子数据时，我们将不知道何时使其缓存无效。

如果单片应用程序决定更改为使用RDS而不是DynamoDB来存储帖子数据，我们将不得不重新实现推荐服务中的逻辑以及访问帖子数据的所有其他服务。

单片应用程序具有解释帖子数据的复杂逻辑 ，例如，如何确定帖子是否应该对给定用户不可见。我们必须在推荐服务中重新实现这些逻辑。一旦整体应用程序更改或添加新逻辑，我们也需要在任何地方进行相同的更改。

即使推荐服务是自己的数据访问模式的错误选项，推荐服务仍然停留在DynamoDB上。

在解耦存储模型中，推荐服务不能直接访问发布数据，也不能直接访问任何其他新服务。发布数据的实​​现细节仅保留在一个服务中。有不同的方法来实现这一目标。

Option A 理想情况下，应该有一个拥有帖子数据的Post服务，其他服务只能通过Post服务的API访问邮政数据。但是，为所有核心数据模型构建新服务可能是一项昂贵的前期投资。

当人员配置有限时，还有一些更实用的方法。根据数据访问模式，它们实际上可能是更好的方式。

在 选项B 中，单一应用程序可让推荐服务知道何时更新相关的帖子数据。通常，这不必立即发生，因此我们可以将其卸载到排队系统。

在 选项C 中，ETL管道生成推荐服务的发布数据的只读副本，以及可能对推荐有用的其他数据。在这两个选项中，推荐服务完全拥有其数据，因此它可以灵活地缓存数据或使用最适合的数据库技术。

解耦“建立服务”和“运行服务”

如果构建微服务很难，那么运行服务往往更难。 当运行服务与构建每个服务相结合时，它会减慢工程团队的速度，团队必须不断重新发明这样做。我们希望让每项服务都专注于自己的工作而不用担心如何运行服务的复杂问题，包括网络，通信协议，部署，可观察性等。服务管理应该与每个服务的实现完全分离。

由于最近在 容器化，容器编排，服务网格，应用程序性能监 控等方面的技术进步，“运行服务”的解耦变得比以往更容易实现。

网络。 网络（例如，服务发现，路由，负载平衡，流量路由等）是运行服务的关键部分。传统方法是为每种平台/语言提供库。它工作但不理想，因为应用程序仍然需要非常繁琐的工作来集成和维护库。通常，应用程序仍然需要单独实现某些逻辑。现代解决方案是在Service Mesh中运行服务。在Medium，我们使用 Istio和Envoy作为边车代理 。构建服务的应用工程师根本不需要担心网络问题。

通信协议 。无论您选择哪种技术堆栈或语言来构建微服务，从一个高效，类型化，跨平台且需要最少开发开销的成熟RPC解决方案开始是非常重要的。支持向后兼容性的RPC解决方案也使部署服务更加安全，即使它们之间存在依赖关系。在Medium，我们选择了gRPC。

一种常见的替代方案是基于>