原文:Walking the wire: Mastering the Four Decisions in Microservices Architecture
作者:Srinath Perera
胖达注:这篇文章发布于2016年3月10日,虽然将近三年了,但是方法论的东西并不会过时。
任何对此文感兴趣的读者请花费50美元/年或5美元/月的价格参加Medium会员计划,否则每月只能查看三篇文章。
一个月一餐盒饭钱,我觉得并不贵,你说呢?
以下为本人对文章的翻译。不对内容负责,也不对任何翻译错误负责,同时不包含任何图片内容,如需查看图片请付费查看原文链接,谢谢。
微服务是使用简单,轻量,松散耦合的服务构建系统的新架构风格,可以相互独立地开发和发布。
如果您不熟悉微服务,我建议您阅读Martin Fowler的帖子。如果您想将其与SOA进行比较,请观看Don Ferguson的演讲。此外,Martin Fowler的“ trade-off of microservices ”和“ when it is worth doing microservices ” 时,可以帮助您确定微服务何时有用。
假设你听过,了解并且相信微服务。微服务架构的追随者面临着一些实际挑战。本文讨论了处理其中一些挑战的问题。我将在其余讨论中使用MSA来表示微服务架构。
决定1:不共享数据库
此处有图
每个微服务都应该有自己的数据库,数据绝对不能通过同一个数据库共享。此规则消除了导致服务之间紧密耦合的常见原因。例如,如果两个服务共享同一个数据库,则第二个服务将在第一个服务更改了数据库Schema时离线。所以,在更改数据库之前,团队必须互相沟通,导致延迟,一切和不使用MSA时一样。
我认为这条规则很好,不应该被打破。
但是,有一个问题。当两个服务共享相同的数据(例如银行帐户数据,购物车)并且需要使用数据库事务来强制一致地更新数据时,我们经常共享数据库。
任何其他解决方案都很难。我们来探讨一下。
解决方案1:如果仅会在一个微服务中发生数据更新(例如贷款审批流程检查余额),则可以使用异步消息(消息队列)来共享数据。
此处有图
解决方案2:如果两个服务都会发生数据更新,请考虑合并这两个服务或使用事务。帖子 Microservices: It’s not (only) the size that matters, it’s (also) how you use them 描述了第一个选项。下一节将详细介绍事务。
处理更新的一致性
我们已经讨论过如何在单个服务更新数据时处理这种情况。让我们讨论当多个服务更新数据时如何对它们进行数据处理。我们在前面的部分讨论过一个例子。
通常,我们使用事务来解决此问题,这在分布式设置中使用时会造成系统缓慢,繁重且昂贵。但是,我们有时可以在不引入事务的情况下解决问题。
有几种选择。
选项1:将所有更新都放在同一个微服务中
如果可能,请避免跨越微服务边界的多个更新。然而,有时通过这样做,你最终会得到较少的服务或糟糕情况下的一个巨大的独石应用,又退回去了。因此,有时候,这是不可能的。
选项2:使用补偿和其他低保证措施
正如著名的帖子“ Starbucks Does Not Use Two-Phase Commit ”所描述的那样,普通世界没有事务。例如,星巴克的咖啡师不会等到您的交易完成。相反,他们同时处理多个客户,同时补偿任何发生的错误。如果你愿意做更多的工作,你也可以这样做。
一个关键点是,如果一个动作失败,你可以补偿。例如,如果您要运送这本书,首先扣除这笔钱,然后运送书籍,如果运费失败,则退还款项。
另一个简单的想法是给用户一个按钮,如果他可以判断它已经过时,就强行刷新页面。此外,有时最终的一致性或超时就足够了。你咬紧牙关,并接受较低的一致性(例如Vogel的帖子是一个很好的起点)。
最后,Life Beyond Distributed Transactions:Anpostate's Opinion 是对所有技巧的详细讨论。
话虽如此,一些用例需要事务以获得正确的结果。它们就必须使用交易。请参阅 Microservices and transactions-an update,权衡利弊并明智地选择。
决定2:微服务安全性
在微服务之前,服务通过在收到请求时调用数据库或身份服务器进行身份验证。
此处有图
在MSA中,我们可以用微服务替换身份服务器,在我看来,这会导致一个大的复杂的依赖关系。
相反,我喜欢“构建微服务”一书中描述的基于令牌的方法,并由下图描述。
此处有图
客户端与身份或SSO服务器通信,对自身进行身份验证,接收使用SAML或OpenIDConnect描述用户及其角色的签名令牌,并在每次请求时将令牌发送到微服务。每个微服务都验证令牌并根据令牌中描述的用户角色授权调用。此模型将身份验证推送到客户端,并在微服务上进行访问控制,同时简化依赖关系。例如,对于此模型,对于同一查询,具有角色“publisher”的用户可能会看到与具有角色“admin”的用户不同的结果,因为他们具有不同的权限。
值得注意的是,客户端可以获取令牌一次并重复使用它,每次session只会发生一次。因此,额外调用的开销很小。
How To Control User Identity Within Microservices?提供有关此方法的更多信息。
决定3:处理微服务组合
这里,“组合”意味着“如何将多个微服务连接到一个流程以提供最终用户的需求”。
大多数使用SOA的组合看起来如下。有一个运行工作流程的中央服务器。
此处有图
SOA组合使用集中式服务器(例如ESB或工作流引擎)。MSA不鼓励使用ESB(例如 Top 5 Anti-ESB Arguments for DevOps Teams)。另一方面,Do Good Microservices Architectures Spell the Death of the Enterprise Service Bus也提供反驳论据。
我不打算在这篇文章中深入ESB太多。但是,我想讨论是否需要一个中央服务器来进行微服务组合。有几种方法可以完成微服务组合。
方法1:从客户端驱动流程
下图显示了在没有中央服务器的情况下执行微服务的方法。客户端浏览器处理流程。帖子, Domain Service Aggregators: A Structured Approach to Microservice Composition,就是这种方法的一个例子。
此处有图
这种方法存在几个问题。
- 现在需要由客户端触发多个呼叫。因此,如果客户端位于慢速网络后面,这是最常见的情况,则执行速度很慢。
- 可能会在浏览器中运行某些逻辑时添加安全问题(我可以破解我的应用程序给我自己发布一笔贷款)
- 以上示例专注于网站,但大多数复杂的组合通常来自其他用例。因此,在客户端组合微服务对其他用例的普遍适用性尚待证明。
- 在哪里保持状态?可以信任客户端以保持工作流的状态吗?使用REST维护状态是可能的。但是,它很复杂。
方法2:协同
从中心位置指定工作流称为编制。但是,这不是协调多个合作伙伴开展某项工作的唯一方法。例如,在舞蹈中,没有一个人指导表演。相反,每个舞者跟随谁靠近就跟他同步。协同将相同的想法应用于业务流程。
典型的实现包括事件系统,其中该过程中的每个参与者收听不同的事件并执行他或她的部分。每个操作都会生成异步事件,从而在流中触发参与者。像RxJava或Node.js这样的环境是使用它的编程模型。
例如,假设贷款流程包括请求,信用检查,其他未偿还贷款检查,经理批准和决策通知。下图显示了如何使用编排实现此功能。请求被放置在队列中,由下一个节点接收,他将结果放入下一个队列,并且该过程一直持续到完成为止。
此处有图
协同就像一个舞蹈。两者都很复杂,需要练习才能正确执行。例如,程序员不知道进程何时完成,是否发生错误,或进程是否卡住。协同需要广泛的监控,来跟踪进度,通知错误或从中恢复。
另一方面,协同创建了松散耦合的系统,这是它的主要优点。例如,您可以在不更改其他节点的情况下向流程添加新节点。您可以在Scaling Microservices with an Event Stream中找到更多信息。
方法3:集中服务器
最后但最简单的选择是集中式服务器(即编制)。
SOA使用两种方法实现组合:ESB或业务流程。MSA提出了一个API网关(例如,Microservices: Decomposing Applications for Deployability and Scalability)。我猜API网关更轻量级,并使用REST / JSON等技术。但是,在纯粹的架构意义上,所有这些都使用中央服务器完成编制。
集中式服务器的另一种变体是“服务于前端的后端”(BEF),它为每个客户端类型构建服务器端API(一个用于桌面,一个用于iOS等)。此模型为每个客户端类型创建不同的API,并针对每个用例进行了优化。有关详细信息,请参阅模式:Backends For Frontends 。
我建议不要对这里的所有选项操心太多,直接从API网关开始,因为这是最简单的方法。您可以根据需要增加切换到更复杂的选项。
决定4:避免依赖地狱
MSA的目标是使服务可以独立发布和部署。要做到这一点,你必须避免依赖地狱。
让我们考虑使用API“A1”的微服务“A”并将升级到API“A2”。现在有两种情况。
- 微服务B可能会将用于A1的消息发送到A2。需要向后兼容性来支持这种情况。
- 微服务A可能必须回滚到A1,微服务C可能继续发送A2版本的消息到A1。
如果要独立发布微服务,则必须处理上述情况。否则,你所有的建立MSA的努力都被浪费了。
通常,处理这些情况的办法是添加可选参数而永不重命名或删除现有参数。然而,更复杂的情况是可能的。
帖子 “Taming Dependency Hell” within Microservices with Michael Bryzek 详细讨论了这一点。Ask HN: How do you version control your microservices? 也是另一个很好的来源。
最后,应该通过时间限制向后和向前兼容性支持,以避免并发症。例如,您可以有一条规则,即微服务不应该依赖超过三个月的API。这将让微服务开发人员最终放弃支持旧版本的一些代码分支。
最后,我想谈谈你的依赖图在微服务架构中应该是什么样子。
一种选择是在需要时自由调用其他微服务。这将创建一个前ESB时代的意大利面建筑。我不是那种模型的粉丝。
另一个极端是说微服务不应该调用其他微服务,所有连接都应该通过API网关或消息总线完成。这将导致一个树形结构。例如,不是微服务A调用B,而是将微服务A的结果带到网关,网关再根据结果调用B. 这是编制模型。现在,大多数业务逻辑都将存在于网关中。是的,这使网关变重了。
我的建议是要么选编制模型,要么辛苦的实现协同。是的,不要选意大利面模式。
结论
微服务的目标是松耦合。精心设计的微服务架构允许您使用一组微服务实现项目,其中每个微服务都是独立管理,开发和发布的。
当您使用微服务进行设计时,您必须密切关注关键,即“松耦合”。有很多挑战,这篇文章回答了以下问题。
- 如何处理需要在两个微服务之间共享数据的场景?
- 如何在保持松散耦合的同时迭代微服务API?
- 如何处理安全问题?
- 如何协同微服务?
谢谢!欢迎评论。
如果您喜欢这篇文章,您可能还会发现以下内容有用。