视频: ä¸è¦å²ç¬æåçæ§ (十一月 2024)
企业软件领域到处都是嗡嗡作响的技术。 我们已经写了很多关于它们的文章，无论是区块链，低代码开发还是其他正在改变我们工作方式的趋势。 您可能以前从未听说过的一个新流行词是“微服务”。
那是设计使然。 微服务是一种基于一组交织的模块化组件而不是传统的“整体”思想（基于由不断增长的代码山组成的应用程序）构建软件的不同方式。 基于微服务的应用在用户界面（UI）方面看起来没有什么不同，无论是在复杂的数据中心应用中还是在可伸缩的云基础架构上托管的Web或移动应用中。
企业应该关心微服务的原因是，该架构在后台可以帮助您的开发和IT团队更快地进行工作和创新，管理基础架构，并降低向应用程序添加新功能的成本和复杂性。 IDC应用程序开发软件研究计划总监Al Hilwa解释说，他如何在考虑文化和技术挑战的同时向高管推销微服务。
希尔瓦说：“在构建新系统时，关键可能是要认识到应该由一个小团队来构建单个微服务。” “第二，整体微服务文化的独立性通常隐含了对编程语言和开发人员工作流多样性的容忍。对执行人员的主要建议是，使用小型团队逐步构建软件，每个团队建立一个连贯的模块并发布一个界面的优势在于，只要以一种有组织的方式管理已发布的API，独立模块就可以以更快的速度独立发展。”
真正的微服务是什么？
希尔瓦（Hilwa）撰写了2015年IDC报告，题为“微服务的出现作为一种构建新软件系统的新架构方法”。 在报告中，他将微服务定义为一种精细的软件体系结构，在该体系结构中，应独立设计和开发应用程序组件，以满足API定义的互操作性要求（意味着，将其捆绑到整个应用程序中）。 但是，微服务并不是凭空存在的。 一个新的体系结构需要强有力的组织支持和IT文化的转变。
微服务也不是由任何一种特定技术定义的，而是随着容器的出现和通过诸如持续交付（CD）和持续集成等开发方法的自动化兴起而增强的长期面向服务架构（SOA）概念的演变。 （CI）。
希尔瓦说：“当今使用微服务的组织通常是出于对加快服务发展步伐的渴望。” “因此，在大多数情况下，微服务在很大程度上使用CI / CD自动化。但是，服务之间的实际部署速度可能会有所不同。我认为关键是要很好地了解内部文化并确保您愿意容忍技术堆栈中更大的权力下放和多样性。”
希尔瓦（Hilwa）所说的“内部文化”在很大程度上是指DevOps，DevOps是一种将软件开发，IT运营和质量保证（QA）组合到单个协作工作流程中的哲学。 DevOps软件初创公司HashiCorp及其创始人长期以来一直是微服务的支持者。 该公司最近获得了2400万美元的B轮融资，其开源用户和企业客户中包括思科，DigitalOcean，Mozilla和Stripe等公司。
微服务是HashiCorp通过其流行的开源工具和不断发展的企业产品套件进行DevOps基础架构开发和应用程序工作流的核心。 HashiCorp的首席技术官兼联合创始人Armon Dadgar使用一个简单的比喻：亚马逊和eBay打破了整体与微服务之间的差异。
Dadgar说：“将Amazon和eBay视为单个应用程序。从最终用户的角度看，它们看起来很相似，但是在幕后，两家公司在构建和架构应用程序时采取了相反的方法。” “亚马逊从一开始就是一堆微服务；它充当一个应用程序。但是，如果您进行搜索，产品目录，购物车，发票，订单流并拆分这些功能，则这两个应用程序将在不同的位置运行机器。”
亚马逊的类比也扩展到亚马逊本身的结构。 Dadgar解释说微服务之类的技术方法是支持向DevOps进行更大流程移动的工具。 杰夫·贝索斯（Jeff Bezos）的“两个披萨规则”有效，因此任何给定的亚马逊团队中只有五到八个人。 如果团队规模扩大，则分为两部分。
亚马逊的组织层次结构开始朝着达德加形容为“功能分解”的方向发展。 然后，在组织和模块化体系结构级别上分开，每个团队都可以自由地进行开发和试验，而无需对每个更改进行协调，同时仍可作为单个内聚应用程序的一部分来运行。
Dadgar说：“ eBay采取了整体的方法；他们将eBay的全部内容构建为一个长达5000万行的代码应用程序。” “微服务方法一开始就更加痛苦，因为模块化和互操作性问题在整体中并不存在。但是当应用程序变得太大时，事情就会开始崩溃。在整体中，不会分解。
“考虑到成千上万的开发人员在单个代码库上进行协作并尝试进行协调。在QA团队中，在应用程序的一侧添加功能可能会在另一侧带来麻烦，因为角色和职责之间没有明确的区分。因此，您开始需要项目经理之间的越来越多的协调和质量保证流程，这可能需要数周和瓶颈的开发，而无论团队的运作速度如何。厨房里的厨师太多了。”
DevOps世界中的容器和微服务
您的企业实现微服务架构的方式将对确定投资是否有回报有很大帮助。 微服务需要大量的前期工作，尤其是在API集成中，它需要确保所有服务之间都能相互通信。 Hilwa解释说，尝试将微服务集成到现有系统中时甚至更加复杂。 他建议企业在可能的情况下构建新系统，而不是为微服务重新架构传统的单体应用程序。
希尔瓦说：“传统的系统体系结构通常涉及大型，复杂的记录数据库系统，并具有精心设计的规范化架构。” “将这样的系统分解成具有各自独立系统的较小组件，需要进行大量的数据库设计工作，并有效地重写大多数核心应用程序逻辑。在大多数情况下，这通常是成本和时间的限制。”
如果您确实要对旧版应用程序进行架构设计，那么Hilwa建议您逐步进行。 尽管微服务比API集成更为重要，但没有其背后的DevOps文化，微服务就无法工作。 HashiCorp的Dadgar说，当涉及到较大的DevOps时，微服务已成为一种工具，可促进更大的流程转变，从根本上改变我们交付应用程序的工作流程。 他指出了HashiCorp和他的联合创始人Mitchell Hashimoto创立公司时提出的道：简单，模块化和可组合。
Dadgar表示：“从某种意义上说，DevOps比微服务更重载。” “但是，企业是由具有不同专业知识的人员组成的：开发人员，操作员，安全人员。然后，您便有了流程以及组织这些人员的方式。然后，您便拥有了支持该流程的工具，这就是微服务和容器的所在。进来吧。”
容器受到Docker的开源激增而普及，远非企业可以用来促进微服务的唯一工具。 IDC的Hilwa表示，容器在CI / CD工作流中以及在某些情况下在部署到生产中时都在现代应用程序中使用。 但他说，微服务也可以利用虚拟机（VM），而无需使用容器。
就是说，谈到业务云的发展方式，Docker容器和微服务是一种强大的工具组合，各种规模和规模的企业都在使用它，从HashiCorp这样的初创企业到Oracle这样的企业巨头。 HashiCorp的Dadgar表示，容器是Dev和Ops（以及通过不同的团队和服务）相互通信的便捷方式。
达加尔说：“我们在开发人员和运营商之间传递的工件是什么？我们要进行彻底的流动和构建？容器是传递的方便单位。” “想想一个在全球范围内运输产品的全球性企业。无论是货船，货运火车还是卡车，它都是贯穿整个系统的同一单元。”
DevOps和微服务仍远未被企业广泛采用，但市场仅在增长。 根据IDC的报告，微服务架构将在未来五年进入成熟阶段。 DevOps文化将在2020年达到50％的组织之后，软件自动化工具的不断发展以及由Amazon Web Services（AWS）和Microsoft Azure等提供的廉价，可扩展的云基础架构的支配之后，这种成熟将发生。
Dadgar表示，即使目前只有一小部分企业采用DevOps和微服务，HashiCorp的订位也已经大大超过了。 在企业销售仅9个月后，它便达到了首个7位数字的收入，这是GitHub上一个每月活跃用户数百万的开源社区的基础。 微服务只是HashiCorp工作流应用程序工具管道和更大的DevOps基础架构路线图的一部分。 但是，该公司构建的所有产品都具有模块化和互操作性，这推动了硅谷最热门的软件初创公司之一的迅速崛起。
达德加说：“四年前，当我们开始时，我们将参加会议并就如何管理基础设施提出我们的愿景。” “我们并没有完全笑出来；我们知道这很早。但是现在，我们的Terraform之类的工具正逐渐成为行业标准。我们将看到竞争压力的多米诺效应，并且从长远来看，我们的角色将与CIO和CTO合作，以了解他们需要采取的流程转变。
“回想一下丰田，”达德加继续道。 “您有很多汽车公司在生产产品，但成本却高于应有的水平。丰田并未重新发明汽车是什么；它们对流程的要求更加严格和严格，从笑柄转向了动力，迫使汽车制造商开始制造汽车。行业中的其他人采用相同的做法来保持竞争力。现在，我们有行业领导者问他们如何获得竞争优势，他们的答案是采用市场上的Google和Amazon的做法。点，它将达到临界点。”
