是微服务的错吗?

admin 2022年11月21日16:47:30安全开发评论15 views2521字阅读8分24秒阅读模式

就在Twitter的部分微服务被新任CEO马斯克勒令下架之际,部分用户很快报告称自己无法正常登录软件。此前,马斯克曾将这些被关闭的微服务称为“膨胀软件”,但粗暴剔除使得一些用户的双因素身份验证出了问题。Twitter最终解决了问题,可微服务在IT架构中的作用因此受到了质疑。

在此次Twitter事件中,砍掉部分微服务就像是用力抽出缠结线团中的一个线头,意外解开了几个重要的结。但借此机会,其他组织也想思考自己能不能不用微服务,还是说微服务架构已经与自身运营体系紧密绑定、一损俱损。

Pulumi公司CEO Joe Duffy就微服务融入IT架构的态势、带来的助益,以及如何在IT管理者的疏忽下成为新的遗留技术债务发表了观点。


 1 
微服务在IT架构中处于什么位置?


在我的脑海里有这样一道光谱,两端分别是单体式架构和完全分布式架构。微服务就处于这道光谱中更偏向完全分布式架构的位置。云计算的普及让我们能够以全新方式思考事物。想想真正的分布式应用程序架构,我们就是从“双虚拟机加单数据库”的时代步步前行,通过托管服务、容器再到无服务器架构最终来到了完全分布式的彼岸。而微服务无疑在其中扮演了重要角色。

现代云确实加速了向这些架构的转变,但不同架构其实各有利弊,绝不是越新越好。微服务虽然活动组件更多、复杂性更高,但也提供了一种将服务置于API边界,借此将复杂度控制在合理范围内的办法。

亚马逊在这方面的早期探索最为典型,因为Bezos要求各团队必须通过API进行通信。这就产生了一种观念,即各个团队分别运行不同的服务,而服务间由软件连通——靠的是API,而不再是人。这有助于不同团队分别独立行动,但又能协同达成约定的功能。不过可以想见,这样的体系也往往会过度膨胀,而且底层的复杂性只是被掩盖住了、并没被真正消除。

一旦把这些麻烦藏在API背后,人们就很容易往那一丢、再也不管。现实情况就是,很多企业实际可能只需要5项微服务,但实际微服务数量却成千上万。这就是所谓过度膨胀,但我认为还算是发展历程中的正常阶段。


 2 
微服务跟清晰分层、井井有条的传统IT架构来比较,孰优孰劣?


微服务当然有自己的优势,它能大大降低系统运行的门槛。它提供API,所以一次API调用就能获得所需功能。其实把功能抽象成微服务是件好事,意味着我们不再需要频繁思考怎么操作这些功能。只需要启动、运行、调用,就这么简单。

微服务也可能成为遗留系统、成为不再增值的系统,但这同样不是坏事——毕竟任何人的脑容量都是有限的,如果把这些已经固化的部分都塞进庞大的单一系统,那就根本没法管理了。借助微服务,我们可以对平台的不同功能做明确划分,然后分别放在API和微服务后面。当然,这种遗产或者说债务也确实会随时间推移而不断累积。


 3 
那有没有人呼吁简化微服务,尝试解决这方面的难题?


其实跟任何事物一样,微服务也有自己的Gartner炒作周期——先是期望过高的峰值,然后走向幻想破灭的低谷。微服务的低谷期应该已经过了,但整个发展历程仍然值得一说。坦率地讲,很多人其实是在不适合的场景中使用微服务,甚至是为了微服务而微服务。

Kubernetes那边也有类似的状况:每个人都想用一把Kubernetes,却没有考虑到自己的需求规模到底有没有必要。微服务在炒作周期中比Kubernetes中走得更远,所以使用方式也更合理一点了。

要解答这个问题,我们可能需要退回一步,想想自己到底要让这套系统实现什么功能。比如说当我们手头有上千项微服务,那就很容易迷失方向,搞不清当初到底想用它们实现什么功能、系统构建的最优方法是什么。另外,微服务在正常使用下也会保持有机增长。刚开始,我们创建服务、发布服务、部署API;接下来就是调用API,再据此构建新的服务。这就创造出了一个相互依存、彼此关联的微服务网络。

如果单体式架构能够满足需求,那不妨优先采用。但随着团队规模的扩大,单体式架构往往开始成为瓶颈。所以正确的答案在于权衡,不存在银弹式的终极真理。


 4 
是否存在最适合的微服务应用场景?与之对应,有没有明确不适用微服务架构的场景?


亚马逊云科技就是典型的微服务应用案例。看看他们的产品组合,400多种不同且彼此独立的服务堆叠起来,而且每项服务都有自己的API。因此亚马逊拥有独特的内部组织方式,各团队就是自己产品和服务的所有者。这种架构跟业务组织是高度统一的,如果不选择这种运营方式,我很难想象他们能够建立起如何庞大的云服务平台。

而相对比较复杂的是那种“灰色”区域,比如说Stripe。Stripe也属于服务集合和产品集合。我敢肯定,其中的身份验证服务跟信用卡计费和其他计量服务肯定彼此独立,而报告跟分析服务又是额外的部分。作为一家物流配送企业,Stripe关注的是产品运输中的实施细节,所以我估计他们肯定是找到了单体跟分布之间的理想平衡。

总之,产品越简单、本质越单一,就越没必要把它拆分成多个彼此独立的服务。


 5 
但如果一家企业深度拥抱微服务,但突然被迫放弃这条路,结果会怎么样?


其实这类架构决策不存在“突然被迫放弃”这种情况,它们反映的可是非常深刻的问题。微服务的优势在于不同事物之间在物理上相互独立,甚至各自运行在不同服务器上并由API连通。这些API肯定会影响性能。

所以要想放弃这样的架构设计,肯定需要审慎考量,比如“既然我们不需要这些服务,能不能直接关掉?”但这并不是微服务特有的问题,只是在微服务架构中容易被忽略的问题。只要运行软件,这样的问题就总会存在。为什么你会有那么多根本不需要的服务?要想保留并整合这么多服务,本身就是会是个重大的架构变化,微不微服务都一样。


推荐阅读:


分布式实验室策划的《Go实战集训营》正式上线了。这门课程通过5天线上集训,4个练习项目,40天课后辅导,和学员一起一步一步基于Go常用框架搭建起一个可以访问MySQL、Redis和第三方服务的Go服务,并进行线上调试,排查问题。培训重实战、重项目、更贴近工作,边学边练,1月7日正式开课。

是微服务的错吗?

原文始发于微信公众号(分布式实验室):是微服务的错吗?

特别标注: 本站(CN-SEC.COM)所有文章仅供技术研究,若将其信息做其他用途,由用户承担全部法律及连带责任,本站不承担任何法律及连带责任,请遵守中华人民共和国安全法.
  • 我的微信
  • 微信扫一扫
  • weinxin
  • 我的微信公众号
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年11月21日16:47:30
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                  是微服务的错吗? http://cn-sec.com/archives/1420992.html

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: