论UI架构在微服务中的重要性

在德国柏林所举办的microXchg大会上,Stefan Tilkov进行了一场名为“Wait, what!? Our
microservices have actual human
users?”的演讲。Tilkov表示,目前对于微服务的各种讨论都倾向于以后端的主题为中心,例如API的风格、服务的查找以及伸缩等等。他认为是时候对微服务应用中最重要的一部分,即用户界面(UI)部分的结构设计多加关注了,这一点是至关重要的。

Tilkov是innoQ的联合创始人之一及首席顾问,他在这次演讲的开篇部分首先分析了前端组件在微服务架构中所扮演的角色,并展示了一系列公众的假设,其中第1条是:“编排工作开销很低”。在基于微服务架构的应用程序中,后端的通信延迟往往是微秒级的(例如数据中心内部的访问),而典型的互联网通信的延迟往往是毫秒级的(例如客户端对于应用后端的访问)。这往往会促使开发者将编排与数据的聚合工作推到后端实现。

“为前端服务的后端”(BFF)这一模式最近开始走红,它被认为是克服在前端进行复杂编排工作的一剂良药。但Tilkov表示,这一模式内在的特性未必会为你带来最优的实现。

我不认为“为前端所服务的后端模式”应该成为你的追求,它只是正好发生在你身上,原因可能只是你修复了某个原本出错的功能而已。某些情况下,BFF或许是一个良好的选择,另一些情况下它或许也是一种合理的选择,但我认为这不是你应当遵循的一种模式。

接下来进入下一个假设,“系统很重要”,它表示BFF模式经常会对应各种系统提供独立的实现,例如web、平板与原生应用,进而催生了各种跨服务连接的出现(从而有可能会造成脆弱的依赖性)。Tilkov对此有着不同的看法,他认为系统并不重要,用户所期待的是一种“跨系统的无缝体验”。与之相对,推荐的实践是应当构建“能够实际完成某些任务”的服务。这种实践同时也能够克服另一个假设,该假设曾经被认为是“SOA的原罪”,即服务最重要。

第4个假设是“前端技术只是一种实现细节”。在谈话的这一部分首先展现了微服务平台常见的后端目标:不依赖于具体实现、较小的接口层、基于标准、独立的部署以及自治的运维。Tilkov希望听众能够仔细思考一下前端平台的概念,并表示:现有的基于web的技术,例如超链接、重定向与嵌入(transclusion)能够与将浏览器视为一种平台这一思想结合在一起,他们已经满足了后端目标中的很大一部分。

对于“可以接受一体性的前端平台”这一假设,Tilkov认为它“只是在某些情况下是正确的”。原生的前端架构往往类似于服务端的一体性架构,他们的目标与限制都有相似之处。可以通过在某种程度上利用组织结构技巧(康威定律)、平台接口、火车发布模型(release
train)以及各种规则以缓解常见的开发与部署问题。

最后的一条假设是“以JS为中心的web应用可以与原生应用表现得一样好”,Tilkov对这条假设的回应是“这种web应用不应该像原生应用表现得那么差!”。他对听众提出了一个要求,在没有必要的情况下,对于选择一体化架构的设计方式应该提出质疑。在向原作者Phillip

Greenspun表示了歉意之后,Tilkov稍稍修改了著名的格林斯潘第十定律,并劝告听众避免重新发明浏览器整合特性,接受一定程度上的低效,并且避免臃肿的模块化实现,例如Java
EE或OSGi等等。

任何足够复杂的JavaScript客户端应用程序中,都包含一个临时特设的、不合规范的、充满程序错误的、运行速度很慢的、只有一半功能的浏览器实现。

总的来说,Tilkov认为只有很少的组织在交付API的同时意识到了UI的重要性。正如上文所述,前端的一体性架构与后端并没有高下之分,他们的性质是相同的。对于浏览器端的开发来说,最重要的一点在于进行模块化的前端交付。如果你正在考虑、或是正在参与向基于微服务的应用的迁移过程,那么你就应当像后端架构一样重视前端的架构。

Stefan Tilkov的演讲“Wait, what!? Our microservices have actual human users?”的视频可以在microXchg的Youtube频道上找到,同时也可以在innoQ网站上找到此次演讲的幻灯片。

本文转自d1net(转载)

时间: 2024-08-01 10:04:00

论UI架构在微服务中的重要性的相关文章

Etsy 技术 VP 谈架构:微服务,单体应用和激光射钉枪?Etsy 在寻找正确的焦点

本文讲的是Etsy 技术 VP 谈架构:微服务,单体应用和激光射钉枪?Etsy 在寻找正确的焦点,[编者的话] Etsy 是美国一个在线销售手工工艺品的网站,网站集聚了一大批极富影响力和号召力的手工艺术品设计师.在 Etsy,人们可以开店,销售自己的手工艺品,模式类似eBay和中国的淘宝.本文讨论了为什么关注点在"微服务"或"单体应用"的标签会干扰思考:Etsy 是如何演进它的技术架构以保证业务发展. John Allspaw一直从事Web相关工作,曾经在Salon

多租户微服务中使用Java Config注册HSF服务

有了速卖通中间件的spring-boot-starter-hsf,在基于Spring Boot微服务中使用HSF,是件简单而惬意的事情. 我们首先来看最简单的服务注册 @HSFProvider(serviceInterface = QasHsfService.class, serviceVersion = "1.0.0.qas", serviceGroup = "HSF") public class QasHsfServiceImpl implements QasH

华为架构师8年经验谈:从单体架构到微服务的服务化演进之路

本次分享的大纲如下: 传统应用开发面临的挑战 服务化实践 服务化不是银弹 服务化架构的演进方向   一 .传统应用开发面临的挑战 挑战1-- 研发成本高   主要体现在如下几个方面:   代码重复率高   在实际项目分工时,开发都是各自负责几个功能,即便开发之间存在功能重叠,往往也会选择自己实现,而不是类库共享,主要原因如下:   从技术架构角度看,传统垂直架构的特点是本地API接口调用,不存在业务的拆分和互相调用,使用到什么功能就本地开发,非常方便,不需要过度依赖于其它功能模块: 从考核角度来

在微服务中如何管理数据

来自Stitch Fix团队的工程副总裁Randy Shoup在QCon纽约2017会议上讨论了如何在基于微服务的应用中管理数据和隔离持久化.他还介绍了将事件(Event)作为微服务的第一类构造.他介绍自己的团队将机器学习技术应用到了业务的各个组成部分,比如购买.库存管理以及风格推荐等. 个性化推荐会基于库存运行机器学习,从而创建出推荐的算法.这些推荐算法随后会被全国范围内的设计师所监管,从而形成个性化风格的推荐. 微服务架构是渐进演化的.像eBay.Twitter和Amazon这样的组织都经历

在微服务中使用领域事件

稍微回想一下计算机硬件的工作原理我们便不难发现,整个计算机的工作过程其实就是一个对事件的处理过程.当你点击鼠标.敲击键盘或者插上U盘时,计算机便以中断的形式处理各种外部事件.在软件开发领域,事件驱动架构(Event Driven Architecture,EDA)早已被开发者用于各种实践,典型的应用场景比如浏览器对用户输入的处理.消息机制以及SOA.最近几年重新进入开发者视野的响应式编程(Reactive Programming)更是将事件作为该编程模型中的一等公民.可见,"事件"这个

在微服务中保证服务的一致性

在近期举办的QCon London大会上,Ben Stopford在他的演讲中极力主张拥抱去集中化的思想.构建基于服务的系统,并通过流处理工具解决分布式状态所引起的问题. Stopford目前任职于Confluent,参与Kafka的开发工作.对他来说,构建基于服务的系统的理由有很多,包括松耦合.边界上下文.易于扩展等等,这些特性让我们能够构建出可以随着时间的推移而不断改进的系统.但是,通过这种方式,我们实质上是在创建分布式的系统,而分布式系统自有其本身的复杂性,并且在延迟与故障等方面还存在着种

微服务架构中API网关的角色

[编者的话]本文主要讲述了Mashape的首席技术执行官Palladino对API网关的详细介绍,以及API网关在微服务中所起的作用,同时介绍了Mashape的一款开源API网关Kong. 本文讲的是微服务架构中API网关的角色API网关提供商Mashape的首席技术执行官Marco Palladino预测,尽管它们在命名方面存在差异,但新出现的服务网格并不完全不同于API网关,两者之间的相似性会随着时间的推移而不断增长. Palladino指出,实际上这两种技术提供的功能很相似.API网关,比

微服务架构的核心要点和实现原理

微服务架构中职能团队的划分 传统单体架构将系统分成具有不同职责的层次,对应的项目管理也倾向于将大的团队分成不同的职能团队,主要包括:用户交互UI团队.后台业务逻辑处理团队与数据存取ORM团队.DBA团队等.每个团队只对自己分层的职责负责,并对使用方提供组件服务质量保证.如果其中一个模块化组件需要升级.更新,那么这个变更会涉及不同的分层团队,即使升级和变更的改变很小,也需要进行跨团队沟通:需求阶段需要跨团队沟通产品功能,设计阶段需要跨团队沟通设计方案,开发阶段需要跨团队沟通具体的接口定义,测试阶段

如何构建微服务架构

本文讲的是如何构建微服务架构[编者的话]"微服务"的概念兴起于四五年前,近几年尤其火热,各大厂都在进行微服务化改造和微服务建设.最近一年来我们也参与了微服务化的改造大军,这里写下一些做微服务系统设计和开发时的切身感受. [3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站]本次培训围绕基于Docker的CI/CD实战展开,具体内容包括:持续集成与持续交付(CI/CD)概览:持续集成系统介绍:客户端与服务端的 CI/CD 实践:开发流程中引入 CI.CD:Gitlab 和 C