杂谈:面向微服务的体系结构评审中需要问的三个问题

面向微服务的体系结构如今风靡全球。这是因为更快的部署节奏和更低的成本是面向微服务的体系结构的基本承诺。

然而,对于大多数试水的公司来说,开发活动更多的是将现有的单块应用程序转换为面向微服务的体系结构,这可能是许多层面上阻碍和冲突的根源。

虽然Greenfield (未开发的)面向微服务的体系结构实现可以坚持对当前微服务的严格解释-设计原则。但在面向微服务的体系结构中,分解的遗留应用程序存在灰色阴影,如果没有其他原因,只能满足预算和时间限制。

在企业管理链的某个地方,有一位业务主管在一个面向微服务的体系结构中查看与这些遗留应用程序相关的分解成本,并将其与遗留代码已经提供的价值进行比较。一旦开发成本超过了预期的收益,业务主管很可能会退出并取消该项目。

这种事经常会发生。

因此,开发经理面临着巨大的压力,要求他们尽快将代码输出。“足够好”地成为转型的理想目标。

现在,这不一定是一件坏事。与等待梦想到来相比,输出工作代码的能力总是更好。但是,“灰色的阴影”是很难管理的,问题就在于如何界定“足够好”的界限。

因此,冲突开始了。一方想要输出他们想要的东西,而另一方则希望做更多的改进。

对你来说,挑战是不要让这些不同学派在本质上是信仰支持的观点上制造一场没完没了的争吵。如果您这样做了,它将造成一种情况,即根本不提供任何代码。现在,冲突可以从许多相互竞争的想法中综合出最好的想法。但是,当话语退化为永无止境的冲突时,它可能是致命的。

我通过集中讨论以下三个问题来处理这类情况,以避免这种冲突:

  • 设计的理由是什么?
  • 风险有多大?
  • 减少风险的计划是什么?

请允许我详细说明。

1. 设计的理由是什么?

当您评估面向微服务的体系结构的设计时,所面临的挑战是将过去的观点转移到理论基础分析上。它的创建主要来自于单个应用程序的分解。任何设计都可能“足够好”,只要你能证明它的好处和价值。

例如,面向微服务的体系结构设计的首选样式之一是采用事件驱动的方法进行服务间通信。具体来说,这意味着您使用消息节点以异步方式在微服务之间传递消息。然而,从长远来看,虽然异步通信更加灵活和可扩展,但消息系统实现比在“面向”微服务的API之间使用同步HTTP调用的设计要复杂得多。因此,当市场时间被关注时,完全有理由将单块应用程序中的特性重构为以HTTP API方式表示的独立的微服务。

与异步服务相比,同步微服务的实现通常不那么复杂。

从长远来看,同步通信不一定是最佳选择,但考虑到从单块应用程序中提取独立的微服务所需的所有其他工作,同步对于第一个版本来说是“足够好”的。因此,这是一个合理的理由。

然而,这并不是说同步方法没有风险。事实上,风险有很多。当涉及到审查面向微服务的体系结构设计时,仅仅说明理由并不是唯一的因素。风险也必须加以阐述。

2. 风险有多大?

所有的设计都有内在的风险。在上面描述的同步设计示例中,这种服务间通信方法可能会导致服务之间类型耦合的风险,由于同步HTTP通信和其他通信的性质而增加延迟增加延迟。

重要的是要让人们知道这些风险,这样就可以根据预期设计的合理性来权衡它们。如果风险是巨大的,再多的理由也是不够的。另一方面,考虑到目前的需求,某些风险可能是可以接受的。诀窍是确保风险在审查过程中得到明确的传达。讨论中已知的风险总是比隐藏的风险更可取,而这种风险可能会在路上造成冲击。此外,如果您以前知道风险,那么随着面向微服务的体系结构的成熟,您可以计划如何在未来的版本中更好地向前迈进。这就是减少风险的原因。

3. 减少风险的计划是什么?

一个明智的应用程序设计人员的一个标志是能够识别他们的设计风险,一旦确定下来他会有远见地阐明一种方法,以减轻这些风险。没有适当的缓解技术的风险识别是思维不完整的标志。

如果面向微服务的体系结构设计有很大的风险和解决这些问题的边际计划,那么设计团队需要认真考虑其可行性。此外,如果缓解计划不切实际-超出项目的专门知识和预算-设计的可行性也需要质疑。这都是平衡的问题。

一个平衡良好的面向微服务的体系结构设计是合理的,因为它想要满足的条件与其固有的设计风险和旨在解决这些风险的缓解计划相权衡。

4. 把它们放在一起

冲突是创造性进程的重要组成部分。有创造力的人往往对自己的想法坚韧不拔。所以,当你把它们放在一个房间里,让他们为面向微服务的建筑设计一个单一的设计时,紧张关系肯定会加剧。事情就是这样的。但要振作起来!冲突是好事。

幸运的是,有了一种理性的方法,用我前面描述的三个问题来审查面向微服务的体系结构设计,您就可以促进客观的讨论,从而产生软件以及时满足您的需求。没有任何设计是完美的,特别是那些分解单个应用程序的设计。但是,交付面向微服务的体系结构有一个很大的好处,这个体系结构足够好有效运作在短期和灵活性足够持续不断改善长期。

原文:https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opinions/3-questions-to-ask-in-a-microservices-oriented-architecture-review

作者:Bob Reselman

译者:遗失的拂晓

9月福利,关注公众号
?
后台回复:004,领取8月翻译集锦!
?
往期福利回复:001,002, 003即可领取!

原文地址:https://www.cnblogs.com/liululee/p/11509836.html

时间: 2024-10-09 13:09:55

杂谈:面向微服务的体系结构评审中需要问的三个问题的相关文章

面向微服务的体系结构评审中需要问的三个问题-咖啡杂谈:Java、新闻、故事和观点

面向微服务的体系结构如今风靡全球.这是因为更快的部署节奏和更低的成本是面向微服务的体系结构的基本承诺. 然而,对于大多数试水的公司来说,开发活动更多的是将现有的单块应用程序转换为面向微服务的体系结构,这可能是许多层面上阻碍和冲突的根源. 虽然Greenfield (未开发的)面向微服务的体系结构实现可以坚持对当前微服务的严格解释-设计原则.但在面向微服务的体系结构中,分解的遗留应用程序存在灰色阴影,如果没有其他原因,只能满足预算和时间限制. 在企业管理链的某个地方,有一位业务主管在一个面向微服务

从无到有构建大型电商微服务架构实际开发案例教程(第三阶段)

从无到有构建大型电商微服务架构实际开发案例教程(第三阶段)课程下载地址:https://pan.baidu.com/s/1oTfj9d-o4URKFzMoVXKxBQ 提取码:8p0s 本课程将手把手带大家从无到有实现一个真实的大型电商微服务项目,该项目是基于真实的知名互联网企业项目讲解的 本课程将讲解如何从无到有搭建一个真实的大型电商微服务项目,涉及的内容较多,录制所需的时间也会比较久,因此整部课程下来售价也比较高,但考虑到课程中讲解的某阶段的知识点,有部分学员可能已经掌握了解,并不需要再次学

面向微服务的企业云计算架构转型

云计算的本质是提高效率,而不是降低成本,公有云就是要提高社会的效率,私有云就是要提高 IT 的效率. 从这个角度看,实施云计算就是做精益运营,而微服务架构为精益运营提供了架构上的保证,因为微服务是小的.容易变化的.容易控制的. 大家好,我是焦烈焱,今天主要介绍普元利用云计算模式,帮助企业实施数字化转型过程中,在技术上遇到的挑战,以及我们解决问题的方法. 首先解释一下什么是数字化?数字化就是把人.事/物和商业联系起来,Garnter 提到未来的企业都是数字化的企业,IT将成为企业核心竞争力,甚至每

在微服务系统开发部署中使用Azure RBAC自定义角色

Azure的官方文档介绍了如何创建用于Azure基于角色的访问控制的自定义角色(RBAC Role). 我们也可以根据同样的原理把RBAC细粒度资源管理运用于微服务产品的开发部署中.(https://www.azure.cn/documentation/articles/role-based-access-control-custom-roles/) 由于快速变化的业务需求,微服务的系统架构设计经常会发生变化,开发团队常常需要增加一个新的微服务,降级一个旧版本的微服务,把一个微服务分隔成2个..

【微服务架构】Spring Cloud之Hystrix(三)

一.雪崩效应 在微服务架构中,由于服务和服务之间可以互相调用,一项工作的完成可能会依赖调用多个微服务模块,但由于网络原因或者自身的原因,服务并不能保证100%可用,如果单个服务出现问题,调用这个服务就会出现线程阻塞,此时若有大量的请求涌入,Servlet容器的线程资源会被消耗完毕,导致服务瘫痪:再加上服务和服务之间的依赖性,瘫痪会迅速传播,给整个微服务系统造成严重的后果,这就是服务故障的“血崩”效应. 服务雪崩效应形成的阶段 1.服务提供者不可用 硬件故障.硬件损坏导致服务器主机宕机,或网络硬件

微服务实施Spring Cloud中踩过的坑(转)

http://tietang.wang/2016/09/08/%E5%BE%AE%E6%9C%8D%E5%8A%A1/%E5%BE%AE%E6%9C%8D%E5%8A%A1%E5%AE%9E%E6%96%BDspring-cloud%E4%B8%AD%E8%B8%A9%E8%BF%87%E7%9A%84%E5%9D%91/ 顺着这篇博客可以发现很多有用的文章.

面试中常常问的三种简单排序方法

/** * 三种简单的排序 * 本类中全部举例都是依照从小到大进行排序 * @author caohaicheng * @time 2014-07-24 */ public class SortDemo { //int[] score={7,10,35,21,78,2,1,9}; public static void main(String[] args) { SortDemo sd=new SortDemo(); System.out.println("********************

eShopOnContainers 是一个基于微服务的.NET Core示例框架

找到一个好的示例框架很难,但不是不可能.大多数是小型Todo风格的应用程序,通常基于SimpleCRUD.值得庆幸的是,Microsoft已经为eShopOnContainers创建了一个基于微服务的.NET Core示例应用程序. eShopOnContainers是 .NET Core示例应用框架,由Microsoft提供支持,基于简化的微服务架构和Docker容器技术. 这个示例应用程序在服务器和客户端是跨平台的,这要归功于.NET Core服务能够在Linux或Windows容器上运行,

【新书推荐】《ASP.NET Core微服务实战:在云环境中开发、测试和部署跨平台服务》 带你走近微服务开发

<ASP.NET Core 微服务实战>译者序:https://blog.jijiechen.com/post/aspnetcore-microservices-preface-by-translator/ "微服务"的概念在 2014 年正式提出之后,越来越多的团队开始用它来设计自己的业务系统,各种微服务框架和开发过程管理方法也同时兴起.不断成熟.微服务设计方法清晰地定义了各个开发团队的业务边界,微服务框架以不同的方式实现了服务之间的协作与集成,根据康威定律我们可以推导这