分类 翻译 下的文章

在过去几年里,微服务成为一个非常热门的话题。“微服务热”是这样的:

Netflix很擅长devops。Netfix做微型服务。因此:如果我做微服务,我就很把控好devops。

在许多情况下,人们都在努力采用微服务模式,而不一定了解成本和收益,也并不知道微服务是否适用于当前问题的具体情况。

我将详细描述什么是微服务,为什么这种模式如此吸引人,以及它们所带来的一些关键挑战。

最后,我将给出一组简单的问题,当您正在考虑微服务是否是适合您的模式时,可能会问自己一些有价值的问题。问题在文章的结尾。
pic1

什么是微服务,它为什么如此流行

让我们从基础开始。下面是设想的一个视频共享平台的实现方式,首先以Monolith(单个大型单元)的形式实现,然后以微服务的形式实现:
Monolith and microservice
这两种系统的不同之处在于,第一种是单一的大单位;第二种是一组小型的、特定的服务。每个服务都有一个特定的角色。

当在这个细节层次上绘制图表时,很容易看到它的吸引力。有许多潜在的好处:

独立开发:小的、独立的组件可以由小的、独立的团队构建。一个组可以对“上传”服务进行更改,而不干扰“Transcode”服务,甚至不知道它。学习组件的时间大大减少,开发新特性也更容易。

独立部署:每个单独的组件都可以独立部署。这使得新特性能够以更高的速度和更少的风险发布。可以在不需要部署其他组件的情况下部署“流”组件的修复或功能。
独立的可伸缩性:每个组件可以彼此独立地缩放。在新节目发布的繁忙时期,可以扩大“下载”组件,以处理增加的负载,而不必增加每个组件的规模,这使得弹性缩放更可行,降低了成本。

可重用性:组件实现一个小的、特定的功能。这意味着它们可以更容易地适应于其他系统、服务或产品的使用。“Transcode”组件可以被其他业务单位使用,甚至可以变成新业务,可能为其他组提供代码转换服务。

在这个层次上来比较,微服务模型比单一模型的好处似乎是显而易见的。但是,如果是这样的话-为什么这种模式只是最近才流行起来呢?我这辈子之前都在搞飞机吗?

既然这么好,为什么以前没做过呢?

这个问题有两个答案。其一是它已经用尽了我们最大的技术能力,其二是最近的技术进步使我们能够把它提升到一个新的水平。

当我开始写这个问题的答案时,它变成了一个很长的描述,所以我实际上要把它分成另一篇文章,稍后再发表。在这个阶段,我将跳过从单个程序到许多程序的演变过程,忽略ESB和面向服务的体系结构、组件设计和有界上下文等等。

那些有兴趣的人可以单独阅读更多关于演变过程的内容。相反,我要说,在许多方面,我们已经这样做了一段时间,但是随着容器技术(特别是Docker)和编排技术(例如Kubernetes,Mesos)的流行程度的最近激增。从技术角度来看,这种模式已经变得更加可行。

因此,如果们搞一个微服务项目,我们就先需要仔细考虑有没有使用微服务的必要。我们已经看到了高层理论上的优点,但实际工作中又会遇到什么样的挑战呢?

微型服务有什么问题?

如果微型服务这么好,为什么我们之前没有使用它?以下是我所见过的一些最大的问题。

增加了开发人员的复杂性

对于开发人员来说,事情会变得更加艰难。如果开发人员希望在可能跨越许多服务的过程中工作,则该开发人员必须在其机器上运行所有这些服务,或连接到它们。这通常比简单地运行一个程序更复杂。

这个挑战可以通过工具缓解,但是随着组成一个系统的服务数量的增加,开发人员在运行整个系统时将面临更多的挑战。

运维者的复杂性增加

对于那些不开发服务但维护服务的团队来说,潜在的复杂性会急剧增加。他们管理的不是几个正在运行的服务,而是管理几十个、数百个或数千个运行中的服务。有更多的服务,更多的通信路径,更多的潜在故障区域。

增加了devops的复杂性

阅读以上两点,它可能会抱怨操作和开发是分开处理的,特别是考虑到devops作为一种实践的流行(我是这一实践的大力支持者)。不能减轻这一点吗?

面临的挑战是,许多组织仍然采用独立的开发和运营团队--而一个这样做的组织更有可能在采用微服务的问题上苦苦挣扎。

对于那些已经接受了“devops”的组织来说,这仍然很难。作为一个开发人员和一个运维人员已经很难了(但是对于构建好的软件来说至关重要),但是也必须理解容器编排系统的细微差别,特别是那些正在快速发展的系统,这是非常困难的。这就引出了下一个问题。

它需要认真的专业知识

如果由专家来做,结果会是非常好的。但是,想象一下,一个组织,也许事情在单一的单一系统下不顺利地运行。增加系统的数量,增加操作的复杂性,会有什么原因使事情变得更好呢?

是的,有了有效的自动化、监控、编排等等,这一切都是可能的。但挑战很少是技术--挑战在于找到能够有效利用技术的人。这些技能目前需求量很大,可能很难找到。

现实世界系统的边界往往定义得很差

在我们用来描述微服务好处的所有例子中,我们谈到了独立的组件。然而,在许多情况下,组件是不独立的。在纸面上,某些域看起来可能是有界的,但是当你进入到模糊的细节中时,你可能会发现它们比你预期的更具有挑战性。

这就是事情会变得极其复杂的地方。如果您的边界实际上没有很好地定义,那么所发生的情况是,即使理论上服务可以单独部署,但是您发现由于服务之间的相互依赖关系,您必须将服务集合作为一个组部署。

这就意味着您需要管理在一起工作时经过验证和测试的一致版本的服务,实际上您没有一个独立的可部署系统,因为要部署一个新特性,您需要仔细安排多个服务的同时部署。

状态的复杂性常常被忽视

在前面的示例中,我提到了特性部署可能需要同时推出多个服务的同步版本。我们很容易认为,合理的部署技术会减轻这种情况,例如蓝色/绿色部署(大多数服务编排平台只需花费很少的精力就能处理这些部署),或者一个服务的多个版本并行运行,使用的通道决定使用哪个版本。

如果服务是无状态(serverless)的,这些技术可以减轻大量的挑战。无状态服务是相当直白的,和他们打交道很容易。事实上,如果您有无状态服务,那么我倾向于考虑跳过微服务,并考虑使用无服务器模型。

实际上,许多服务都需要状态。我们的视频共享平台的一个例子可能是订阅服务。订阅服务的新版本可能以不同的形式将数据存储在订阅数据库中。如果同时运行两个服务,则同时运行两个模式的系统。如果您执行蓝色绿色部署,而其他服务依赖于新形状的数据,则必须同时更新它们,如果订阅服务部署失败并回滚,它们可能也需要回滚,从而产生级联后果。

同样,我们可能会很容易认为,对于NoSQL数据库,这些模式问题消失了,但它们没有。不执行模式的数据库不会导致无模式系统--它们只是意味着模式倾向于在应用程序级别而不是在数据库级别进行管理。理解数据的形状及其演变的基本挑战是无法消除的。

沟通的复杂性往往被忽略

当你建立一个相互依赖的大型服务网络时,可能会有很多的服务间通信。这导致了一些挑战。首先,有很多事情可能会失败。我们必须期望网络呼叫将失败,这意味着当一个服务呼叫另一个服务时,它应该至少需要重试几次。现在当一个服务可能调用很多服务时,我们最终会遇到一个复杂的情况。

用户上传视频共享服务中的视频。我们可能需要运行上传服务,将数据传递到转码服务,更新订阅,更新建议等等。所有这些调用都需要一定程度的协调,如果事情失败,我们需要重试。

这个重试逻辑可能难以管理。试图同步做事往往会导致站不住脚,失败点太多。在这种情况下,更可靠的解决方案是使用异步模式来处理通信。这里面临的挑战是异步模式固有地使系统具有状态性。如前所述,分布式状态系统和系统很难处理。

当一个微服务系统使用消息队列进行服务内通信时,你基本上有一个大的数据库(消息队列或代理)将这些服务粘合在一起。同样,虽然起初看起来似乎不是一个挑战,但其实不然。X版本的服务可能会写入某种格式的消息,当发送服务更改发送的消息的详细信息时,依赖于该消息的服务也将需要更新。

可以有许多不同格式的消息处理服务,但这很难管理。现在,在部署新版本的服务时,您可能会有两次不同版本的服务尝试处理来自同一队列的消息,甚至可能是由不同版本的发送服务发送的消息。这可能会导致复杂的边缘情况。为了避免这些边缘情况,仅允许特定版本的消息存在可能更容易,这意味着您需要将一组服务的一组版本作为一个整体来部署,以确保先前版本的消息得到适当的排除。

这再次突出表明,独立部署的想法可能不会像预期的那样持有细节。

版本控制可能很难

为了缓解前面提到的挑战,版本控制需要非常谨慎的管理。再次,可以有一种趋势,假设遵循像semver这样的标准将解决这个问题。它不。Semver是一个明智的使用惯例,但是您仍然需要跟踪可以一起工作的服务和API的版本。

这可能会非常迅速地变得非常具有挑战性,并且可能会导致您不知道哪个版本的服务实际上可以一起正常工作。

在软件系统中管理依赖关系是非常困难的,无论是节点模块,Java模块,C库还是其他。当一个实体消费独立组件之间的冲突的挑战是很难处理的。

当依赖关系是静态的时候,这些挑战是很难处理的,并且可以进行修补,更新,编辑等,但是如果依赖关系本身是实时服务,那么您可能无法更新它们 - 您可能需要运行许多版本(已经描述过这些挑战),或者直到整个系统得到修复。

分布式事务

在需要跨操作交易完整性的情况下,微服务可能会非常痛苦。分布式状态很难处理,很多小的单位可能会很难进行编排交易。

试图通过使操作幂等性,提供重试机制等来避免这个问题可能是诱人的,在许多情况下这可能起作用。但是你可能有一些情况,你只需要一个事务失败或成功,而不会处于中间状态。解决这个问题或者在微服务模型中实现它的努力可能是非常高的。

微服务可能是变相的庞然大物

是的,单独的服务和组件可能是孤立部署的,但是在大多数情况下,您将不得不运行某种编排平台,比如Kubernetes。如果您使用的是托管服务,例如Google的GKE 5或Amazon的EKS 6,则会为您处理管理群集的大量复杂性。

但是,如果您要自己管理集群,那么您正在管理一个庞大而复杂的关键任务系统。虽然单个服务可能具有前面所述的所有优点,但您需要非常小心地管理群集。这个系统的部署可能很难,更新可能很难,故障转移可能很困难等等。

在许多情况下,整体效益仍然存在,但重要的是不要轻视或低估管理另一个庞大而复杂的系统的额外复杂性。托管服务可能会有所帮助,但在很多情况下,这些服务都是新兴的(例如,Amazon EKS只是在2017年底才宣布)。

微服务热之死!

通过仔细考虑决定避免疯狂。为了帮助解决这个问题,我已经注意到了一些你可能想问自己的问题,以及答案可能表明什么:
微服务热之死
你可以在这里下载PDF副本:microservice-questions.pdf

最后的想法:不要混淆微服务和架构

我故意避免这篇文章中的“a”字。但是,我的朋友佐尔坦(Zoltan)在证明这篇文章的时候提到了一个很好的观点。

没有微服务体系结构。微服务只是组件的另一种模式或实现,只不过是另一件事。无论是否存在于系统中,都不意味着系统的体系结构得到了解决。

微服务在许多方面与包装和操作的技术过程有关,而不是系统的固有设计。组件的适当边界仍然是工程系统中最重要的挑战之一。

无论您的服务是否在Docker容器中,您总是需要仔细考虑如何将系统放在一起。没有正确的答案,并有很多选择。

本文翻译自http://www.dwmkerr.com/the-death-of-microservice-madness-in-2018/

它是怎样工作的
WebAssembly的一个基本原则是与现有的JavaScript世界很好地集成。这包括从技术上的事情,如可集成性和共享安全策略(相同来源),到工具集成,例如支持Web浏览器的View Source功能。

为了实现这一目标,WebAssembly为工具和人工阅读器定义了二进制格式和等效文本格式。从技术上讲,文本格式使用S表达式(S-expressions),因此它看起来如下所示。
1.png
然而,这些工具可能会显示出更类似于这种表达式的东西(例如来自文档)。
2.png
您可能想知道为什么使用C++作为示例。这是因为WebAssembly最初发布(MVP)的目的是支持C/C++。其他语言稍后才会出现,目前它们正在发展中。这是出于几个技术和实际原因而选择的:

  1. WebAssembly的MVP不支持垃圾收集(它正在进行中)。
  2. C/C++到WebAssembly编译器的实现可以依赖于一个现成的测试工具,比如LLVM(最常用的编译器工具之一)。
    WebAssembly开发人员使用LLVM来减少获得工作产品所需的工作量。此外,这使得它们能够轻松地与其他与LLVM一起工作的工具集成,比如Emscripten。

有了MVP,真正的程序员就可以进行测试和使用,从而可以相应地改进WebAssembly。

WebAssembly Tools
目前,官方的WebAssembly工具只能编译C / C ++到WebAssembly,尽管其他开发者已经开始着手增加对其他语言和平台的支持(以前我们提到.NET和Rust)。但是,即使使用官方工具,也可以通过两种方式将其用于Web开发:

以文本格式编写WebAssembly并使用提供的工具将其转换为二进制文件
使用基于这些工具的第三方工具
第一种选择对于常见的应用来说并不实用,但是如果您想要了解这种格式的内容,或者开始将它们集成到自己的工具中,那么这种方法就是一种方法。实际上有两个工具包:WebAssembly二进制工具包和Binaryen。

WABT包含开发工具和/或用于与WebAssembly一起工作的工具:

它完全支持格式规范
它可以从文本格式转换
它包括一个解释器
简而言之,它确保了对WebAssembly格式数据的干净而方便的访问,以便您可以使用它。

另一方面,Binaryen是一个在编译器基础结构中使用的工业级工具包:

它可以与WebAssembly代码或用于编译器的控制流图形式一起使用
它优化了许多代码,包括标准优化和针对WebAssembly的特定代码
它可以编译from / to asm.js(JavaScript的子集),Rust MIR(Rust的中间语言)和LLVM
所以,这个工具包已经被集成到你的生产后端。

从本质上讲,两者都允许您创建操作WebAssembly的工具,但是WABT是为在开发(例如静态分析)期间使用的工具而设计的,而Binaryen则用于创建生产WebAssembly(例如编译器)。
这些工具非常适合开发工具和编译器相关产品的人:他们提供开发工具和即用型生产工具。 但是,它们对于普通的开发人员来说并不理想,因为他们有一个更简单的方法。

如果你需要建立这样的工具,还有第二个选择:从零开始构建所有东西。 如果您需要自定义编译器或解释器来使用您自己的语言,则需要使用最佳性能或轻量级工具。 由于我们已经使用了WebAssembly,所以我们已经创建了一个库来帮助您(和我们)使用WebAssembly:WasmCompilerKit。 它基本上是一个Kotlin库,可以用来加载WASM文件,修改它们并生成它们。 鉴于它是用Kotlin编写的,您可以从Java和Scala中使用它。 我们正在考虑在一个针对JavaScript的多平台Kotlin项目中进行转型。

简介
有一个新的武器,让javascript开发人员在提高性能和生产力的同时,选择他们最喜欢的编程风格。这种武器就是WebAssembly,它将彻底改变客户端的Web开发。
WebAssembly,或wasm,是一种用于浏览器客户端脚本的底层的字节码格式。如果您使用过JVM或.NET,就知道JVM或.NET会将您使用的语言(java、c#等)编译到目标字节码。WebAssembly也扮演着同样的角色,所以当您将软件编译到WebAssembly时,您的软件就可以在所有支持它的平台上使用,换句话说,所有浏览器都可以使用。
实际上,WebAssembly是由浏览器开发人员在现有JavaScript引擎的支持下实现的。本质上,它是用来代替JavaScript作为网站上编译器和转发器的目的地。例如,它的开发人员现在可以编译到WebAssembly,而不是将类型记录编译成JavaScript。简而言之,它不是一个新的虚拟机,它是每个浏览器中包含的相同的JavaScriptVM的新格式。这将使得不使用JavaScript就可以利用现有的JavaScript基础设施。
最小可行产品的设计于2017年3月完成,现在已经为每个主要浏览器准备好了实现。

首先,新的WebAssembly格式承诺在解析性能方面取得显著的进步:

为WebAssembly所考虑的二进制格式可以本机解码,比解析JavaScript快得多(实验显示,速度超过20×10)。在移动平台上,大型编译代码只需20-40秒就能解析,因此本机解码(尤其是与其他技术结合起来,比如流传输以获得比gzip更好的压缩)对于提供良好的冷负载用户体验至关重要。
-WebAssembly FAQ

请注意,我们讨论的是解析性能,而不一定是执行性能。因为在许多情况下,它将在现有的JavaScript引擎上运行。然而,仅仅是解析性能的提高就允许在以前开发的Web软件上使用。例如:虚拟机、虚拟现实、图像识别等。

第一批生产用户可能会成为游戏引擎开发人员,因为他们总是在寻找最佳的性能。在WebAssembly之前,他们所希望的最好的是asm.js(一种简化的JavaScript,为速度优化),这是一种很酷的技术,但实际上并不适用于许多游戏。我记得我尝试过著名的演示史诗城堡(现在离线)由虚拟技术。它实际上运行平稳,但是下载和解析代码需要大约15分钟,这显然不适合快速游戏。

事实上,Autodesk计划支持WebAssembly,支持他们的Stingray游戏引擎和团结技术,他们是团结游戏引擎的创建者,早在2015就开始试验WebAssembly。Rust开发人员也已经在努力支持WebAssembly在Web上运行Rust代码。

它能为你做些什么?
在更大的方案中,WebAssembly的出现意味着您将不再被迫在Web上使用JavaScript,因为它是浏览器中唯一运行的东西。JavaScript名声不好,但实际上它是一种很好的语言,用于快速编写小脚本。问题是,目前您被迫使用所有您需要在网上运行的其他东西,这对于许多大型项目来说是一个问题。

确实,您可以使用更好的JavaScript版本,比如类型记录,甚至是新的语言,比如Kotlin。但是,最终它们都必须编译成JavaScript。反过来,这也给JavaScript开发人员带来了问题,这些问题基本上必须支持所有场景和所有编程风格。WebAssembly将改变这种状况,让每个人都专注于他们能做得更好的事情。

这还不是全部:将WebAssembly移植到其他平台是可能的。这意味着,如果您用编译成WebAssembly的语言编写软件,那么您可能能够在.NET上运行它。事实上,它允许重用Web上已有的JavaScript基础设施,这意味着您已经可以在生产中使用它。

然而,这并不是唯一的选择。您可以为您的需要创建自己的特定实现。您可以为您的语言创建一个优化的编译器。您可以从头创建它,也可以将WebAssembly支持添加到现有的编译器中。因此,您可以利用所有其他WebAssembly模块。

例如,您可以为公司内部使用的DSL创建一个WebAssembly编译器,并使其在客户端的Web上运行,而无需使用诸如Oracle Java插件或AdobeFlash之类的自定义插件。

本文翻译自introduction-to-webassembly

美国职业棒球大联盟
很多名人和运动员使用微博,人人网和Instagram等社交网络与粉丝进行互动并不是秘密。 但是,因为这些平台上的水军、键盘侠太多,导致这些互动并不能深入。 至少这是MLB球员的想法。。
成人棒球运动员协会(MLBPA)正在推出一个名为“Infield Chatter”的应用程序。

该应用程序本质上是一个定制的社交应用,仅供选手和粉丝使用。

像其他社交网络一样,每个人都有自己的个人资料,可以发布图片,视频等。您可以跟随自己喜欢的运动员并对他们的帖子发表评论,他们可以回复。

还有一些更独特的功能 - 例如问答环节和比赛,以赢得玩家的纪念品和玩家独特的体验。其中有一点很体现棒球特色 - 该APP不用“喜欢”,而是用“碰拳”来表示对帖子的肯定。
iphone版界面
超过1,000名MLB运动员已经注册了该应用。 这意味着,粉丝们从第一天开始接触已经可以接触大量的内容。

类似的程序通常会遇到一个“先有鸡还是先有蛋”的问题。没有运动员入驻APP,就没有粉丝入驻;没有粉丝入驻,这应用也将难以发展下去。幸好由于该APP是由MLBPA发起的,因此,联盟中的每个运动员都有兴趣(无论是在职业生涯上还是在潜在的经济上)看到这个APP的发展。

MLBPA表示,APP是根据运动员的要求构建的,他们希望以更个性化的方式与粉丝进行互动,并且可能在此过程中发展个人品牌。 虽然像微博和Instagram这样的平台肯定有很大的影响力,但我们粉了太多人,以致于很容易错过我们实际想要看到的内容。

所以当一个玩家可能有一百万粉丝时,很可能这些粉丝也跟随数以百计的其他账号,比如新闻,娱乐,或者其他球类运动或者其他领域的账号。如果使用该APP(Infield Chatter),则棒球迷们便可以专注于棒球领域。

外场手Rajai Davis说:其他社交媒体就是达到目的,没关系。 但是,这些网站上有很多疯狂的活动,并不总是发布个人资料的最安全的地方。 直到现在,棒球迷还没有一个好地方。 我认为这是棒球选手们同意一起工作的最好的方案之一。

该应用程序与一个名为Honeycommb的创业公司合作建立,它帮助为一群粉丝建立社区。 他们最近为Lady Gaga建立了一个自定义应用程序,可以在比微博等其他社交网络允许的更个性化的级别上与粉丝进行互动。

到目前为止,该应用没有做任何盈利计划。 这样专门的粉丝的平台,很有吸引力,或许能够吸引一些广告商的注意。这意味着如果足够的粉丝加入,MLBPA可能会有一些不错的广告机会。

本文翻译自:https://techcrunch.com/2017/04/18/mlb-players-are-launching-a-new-social-network-just-for-their-fans/