[译] 选择 FaaS 还是微服务?

标签: dev | 发表时间:2019-04-17 00:00 | 作者:
出处:http://itindex.net/relian

作者:Christian Posta
译者:李琪
审校:孙海洲、吴钧泽
原文:https://dzone.com/articles/faas-vs-microservices

在做项目的云原生改造时我们可以采用微服务架构。DevOps和自动化构建两方面的成功经验对微服务的实践很有帮助。经过一段时间的实践,你可能会有将微服务架构推广到其他部门的想法。而你担心微服务本身的复杂性和分布式系统的高维护成本会让其他部门难以接受它。可能在我们想方设法解决微服务带来的问题时,总会有些人觉得这样做毫无意义。因为现在技术发展如此之快,总会出现更好的技术方案,你能保证自己在微服务领域所做的工作最后没有白费吗?

我认为不会白费!

现在“serverless”和“functions-as-a-service”(FAAS)还处于早期的炒作阶段。有些人觉得serverless就是下一代的微服务,所以我们应该跳过当前的微服务模式而直接采用serverless。其实这种说法是有点夸大其词。作为架构师或开发者,我们通过学习新技术来提升自身能力让自己变得更"值钱"并没有错。但我们也要以务实态度来判断是否应该采用新技术。虽然持续跟进最新技术是我们作为架构师的职责所在,但掌握在之前的产品和IT部门引用新技术的时机也很重要。我们可以通过下面的模块来理解微服务架构和serverless,从而让它们可以更好的融入我们的技术栈。

首先,我们需要知道为什么我们需要微服务。选用微服务架构的主要原因就是避免项目的体量阻碍产品的迭代,所有微服务其他的优势都是基于这点。更快的迭代速度意味着可以更快的为客户交付新功能/修改,从而更快的验证这些改动能够带来的效果。我们需要快速的知道自己所做的努力是否能够带来好的效果,如果不能就要马上调整方向。快速迭代就是微服务架构的核心优势。

对于大多数的团队而言,至少有一部分应用能从微服务的迭代过程中获益。因此作为架构师或开发者,我们不要因为采用微服务有门槛就对其失去信心。实践微服务的重要步骤就是确定和测量改进指标。改进指标一般可以为每天迭代应用的次数、保证迭代应用稳定性的方法等。

另一方面,不是所有的应用都需要用这种松散而复杂的方式来保证服务的迭代速度。如果只想简单做个应用来验证自己创意的商业价值,那你完全可以选择更加适合的架构。这时采用MVP测试(最小可行性测试)就是个很好的方案。如果你因为商业价值很低而打算放弃的话,那也只是放弃了一个MVP应用。你可以非常快的迭代它并从潜在的用户中获得反馈。在这种情况下,你可能需要根据反馈反复修改API、功能边界、组件等。所以过早就将组件功能做成分布式的服务也会拖慢产品的发布速度。你想修改分布式组件和它的api就必须在各个团队间进行协调。

上述观点能够反映出微服务架构和单体架构适用不同的场景。而事实上并没有所谓"一招鲜吃遍天“的方案。当我们在微服务架构和单体架构之间纠结时,还需要考虑到所需服务是否已经存在以及它提供服务的方式(第三方服务/公司内部服务)。我们完全可以充分利用当前已有服务来构建我们的应用,不必重新购买硬件、安装和修补操作系统,以及优化服务从而达到最高吞吐量,而这也正是云及其服务存在的意义。云供应商和他们的合作伙伴能提供数据库、消息队列、缓存、CDN和其他更高级的功能: 例如语言翻译、地图/地理空间地图、天气等。我们可以组合各种按量付费的服务来构建自己的应用。如果在使用某个服务的时候无需关心安装、参数和容量等问题,其实我们就已经在采用serverless架构了。serverless架构的特点就是可以重用已经存在的service,而无需关心运行服务需要消耗些什么。

函数即服务和serverless具有某种联系,因为它利用了缩小到单个应用程序函数的范围的计算模型,而这有助于将各种服务组合在一起构建应用。在这种模型下,功能按需分解,你只需为使用的功能付费。它特别适合对我们使用的服务进行按需计费和按量付费。这样一来我们能够构建弹性应用,而不需要考虑复杂的技术问题。将这些复杂的技术问题外包给别人可以让你更专注于为客户提供商业价值。

但是将这部分能力外包不总是可行的。如果选择云服务,我们就丧失了对程序运行时、具体功能、bug修复和接受监管的控制力。这也是需要考虑的一部分。

serverless不一定是完整的“公有云或无云”方案。如果以单个组织的角度来看,"serverless"可能只是代表整个体系的其他部分。例如:零售业务可以为组织内部其他服务或第三方提供“购买“服务以支持诸如分析、推荐以及其他使用“购买”服务的应用。利用定义良好的API和订阅并消费API的工作负载,你可以在自己的基础设施为微服务应用或单体应用提供serverless能力。在很多时候这其实就是服务向SOA架构进化的方向。但它们之间最大的不同就是在你将组织看作一个整体时,自己给自己的其他部分提供服务并不算serverless。因为此时还是需要自己手动的去安装、管理和更新应用。

最终采用哪种方案其实取决于很多因素,例如:业务、商业目标、软件部门对该技术的熟练度和历史遗留问题等。如果你觉得应该采用微服务架构,那就不要因为其他新技术而分心。我们可以持续跟进最新技术,从而保证适时的采用它们。总的来讲,不管是微服务架构、单体架构还是serverless架构,它们都有自己的应用场景。

相关 [选择 faas 微服务] 推荐:

[译] 选择 FaaS 还是微服务?

- - IT瘾-dev
作者:Christian Posta. 原文:https://dzone.com/articles/faas-vs-microservices. 在做项目的云原生改造时我们可以采用微服务架构. DevOps和自动化构建两方面的成功经验对微服务的实践很有帮助. 经过一段时间的实践,你可能会有将微服务架构推广到其他部门的想法.

微服务架构的基础框架选择:Spring Cloud还是Dubbo?

- - 程序猿DD
最近一段时间不论互联网还是传统行业,凡是涉及信息技术范畴的圈子几乎都在讨论 微服务架构. 近期也看到各大技术社区开始组织一些沙龙和论坛来分享Spring Cloud的相关实施经验,这对于最近正在整理Spring Cloud相关套件内容与实例应用的我而言,还是有不少激励的. 目前,Spring Cloud在国内的知名度并不高,在前阵子的求职过程中,与一些互联网公司的架构师、技术VP或者CTO在交流时,有些甚至还不知道该项目的存在.

Dubbo将积极适配Spring Cloud生态,Spring Cloud体系或将成为微服务的不二选择!

- - 程序猿DD
2016年,我在博客中发表过一篇 《微服务架构的基础框架选择:Spring Cloud还是Dubbo. 在这篇文章中,我主要对比了Spring Cloud与Dubbo所具备的能力,并阐述了个人推崇Spring Cloud的原因. 但是,最近各大技术社区出现了不少类似的文章,观点比较激进,对于Spring Cloud的褒扬远胜于Dubbo,但是这些评价很多都忽略了Spring Cloud与Dubbo在设计视角上的不同.

初识微服务

- - ITeye博客
微服务架构越来越火,有必要学习一下. 软件开发过程中碰到什么问题. 一个简单的应用会随着时间推移逐渐变大. 在每次的sprint中,开发团队都会面对新“故事”,然后开发许多新代码. 几年后,这个小而简单的应用会变成了一个巨大的怪物. 一旦你的应用变成一个又大又复杂的怪物,那开发团队肯定很痛苦. 敏捷开发和部署举步维艰,其中最主要问题就是这个应用太复杂,以至于任何单个开发者都不可能搞懂它.

谈微服务架构

- - 人月神话的BLOG
其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是本质还是紧耦合的,这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的.

微服务性能模式

- - 互联网 - ITeye博客
前言:基于微服务系统越来越普遍. 下面我们就来看看五种常见的特定微服务性能的挑战,以及如何应解他们. 背景:在IT界微服务架构为基础的系统越来越多, 每一个应用系统都集成了不同的组件和服务,几乎所有的特定业务应用程序都需要集成一个或更多的应用服务. 但是一个综合性系统集成不同的服务这无疑是一个巨大的挑战.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

从Excel到微服务

- - 乱象,印迹
Excel很老,Excel很土,Excel一点也不sexy;微服务新,微服务很潮门,微服务很高大上. 那么,Excel和微服务有什么关系. 上个月看了篇文章,The Unbunlding of Excel. 作者认为,对于初创公司(尤其是非“纯IT”初创公司)来说,Excel几乎包办各种工作. 想做轻量级的CRM,可用Excel.

微服务框架Spring Cloud介绍 Part2: Spring Cloud与微服务

- - skaka的博客
之前介绍过 微服务的概念与Finagle框架, 这个系列介绍Spring Cloud.. Spring Cloud还是一个相对较新的框架, 今年(2016)才推出1.0的release版本. 虽然Spring Cloud时间最短, 但是相比我之前用过的Dubbo和Finagle, Spring Cloud提供的功能最齐全..

转载 选择

- bravusliu - caowumao的博客