现代企业架构下的微服务

本文讲的是现代企业架构下的微服务【编者的话】微服务架构获得了如此多的关注,大多数的企业IT从业者也正好奇它是如何影响其他的架构模式的:比如企业集成和API管理。

本篇博文的目的是提供一个视角: 在我们引入了微服务架构到企业中以后,现代的企业机构会看起来是什么样子。(如果你对微服务架构还很陌生的话,参阅我的前一篇博文。)

关于微服务如何适用到总体的IT版图的讨论, 我以解读Gartner关于微服务的报告来开始。

微服务架构,本质上是消除了很多的复杂性,包括设计的,开发的,部署的,以及跨服务/系统通讯的。

当时,复杂性虽然从微服务层给消除了,去要其他一些的组件/层来满足。例如,因为MSA不推荐使用ESB来做中央总线,所有原来由ESB做的工作,例如服务编排,不同系统间的路由和集成需要被其他的组件来完成,包括微服务本身。

内部和外部架构

为了在真实的IT解决方案中使用MSA,我们需要满足以上提到的两种需求。Gartner建议MSA有2种不同的架构域。

  • 内部架构: 不太复杂的纯微服务组件都归类到‘内部架构’下;
  • 外部架构: 交付围绕微服务构建一个解决方案所需的平台能力。

事实上,最终的企业架构是内部和外部架构的合体,也就是现代的基于微服务的企业IT架构。

带有微服务的现代企业架构

微服务架构鼓励企业将所有IT解决方案以微服务的方式构建而不使用任何中间集成产品,例如ESB。但是,除非是你白手起家,没有任何内部私有的遗留系统,否则这就是不切实际的方案。在一个大型的组织或者企业中,你不可能简单的将所有的软件系统,服务以及方案都转化为微服务。但是这样的组织希望使用微服务架构来构建敏捷可扩展的软件方案。因此,我们真正需要的是一个微服务与传统已经存在的单体架构系统的混合体。

图 1.1 带有微服务,企业级集成和API管理的现代企业架构

图1.1 展示了一个高层次的现代企业IT架构总览。这里你可以看到我们使用了一个包含有微服务和现存系统的混合架构。这与Gartner所展现的内部外部架构模型类似。

当你将MSA引入到你的组织中时,以下的关键设计决策是你需要采用的:

  • 当任何有需要的时候都使用微服务架构来构建解决方案,试着或者MSA带来的所有好处。
  • 企业集成仍然需要:因为我们需要一个混合方案,你仍然需要使用ESB这样的集成软件给所有的内部系统和服务做集成。
  • 你不能舍弃大多数现存的系统,但是新的微服务可能需要调用这样的单体系统来满足不同的业务需求。在这种场景下, 你可以使用底层的集成软件/ESB,微服务可以调用集成服务器来连接到不同的系统。
  • “新”的ESB: 虽然类似于ESB这样的集成软件对于现代企业架构可能仍然是需要的,但是这种工具再也不能当作中央总线了。组织应该寻求轻量级的高性能的可扩展的集成软件来取代这些笨重的集成框架。
  • API管理: 微服务可以通过网关来暴露,所有的API管理技术都在这一层来实现。 所有其他的需求,例如安全,阀门,缓存,计费,监控要在网关层完成。非微服务架构的服务(传统的SOA服务)也可以通过API网关来暴露。

现在我们近距离看一下微服务层,看看他们如何与现实场景中的服务交互。

集成微服务

在微服务领域经常被问到的问题是“微服务能够互相通讯吗?” 或者“如何利用已有的微服务来构建新的微服务?“

事实上,微服务架构注重针对有限的一个特定的业务范围来构建微服务。因此当提到基于MSA来构建IT解决方案, 则不避免的需要甬道已经存在的微服务。微服务之间的交互可以使用传统的点对点的方式,但是这种方式有点脆弱。因此我们需要坚持一些微服务集成的最佳实践。

  • 使用一个网关来暴露微服务:在所有的微服务之间放置网关,所有的客户仅仅能通过网关来使用微服务。
  • 微服务之间无直接调用: 微服务不能直接调用其他的微服务。所有的调用必须通过网关。

现在我们来看看微服务交互方面的技术细节。

微服务层的编排

当你需要调用多个微服务来实现一个业务需求时,你可以构建另一个微服务(这也是关注一个特定的业务领域),它会组合对所有需要的微服务的调用,汇总最终的响应并发回到原始客户手里。

图 1.2 微服务层实现的服务编排

例如, 图1.2描绘了一个场景,我们有ABCD四个微服务。现在我们要实现一个新的业务功能,需要顺序的调用A和C, 然后提供一个汇总后的回复。我们可以针对这个需求来创建一个新的微服务(微服务E),它的编排逻辑包含依次调用A和C。所有的微服务调用通过网关完成。如果微服务E需要单独扩展,则可以扩展E, 必须的时候扩展A和C。

网关层的编排

实现相同业务场景的另一个实现方式是将编排逻辑引入到网关层。在这种情况下,我们不需要引入一个新的微服务,但是网关上的虚拟服务层要负责编排工作。

图 1.3 网关层实现的服务编排

如图1.3,某个服务调用A和C,它可以在网关层里面来实现(大多数的微服务网关都支持这个特性)。

得上需要扩展这个新的业务功能时,我们必须要扩展网关,微服务A和C。这种情况下,网关有点变成了单体应用因为它也负责路由其他的微服务请求。

Choreography风格

另一个实现微服务交互的可能方式是使用异步消息方式,例如MQTT、Kafka。在这种场景下没有中央组件负责服务交互。服务交互使用基于消息的发布订阅方式。

结论

到此,关于如何在现代企业IT版图中使用微服务架构(MSA),我们可以有如下总结:

  • 微服务不能包治百病:它不可能解决所有企业IT的需要。因此我们扔需要将它与现有的架构一起使用。
  • 大多数企业都不能将他们所有的企业IT系统都转化为微服务。实际上,他们会使用微服务架构去解决某些应用场景的需求,从而充分利用微服务的优势。
  • 企业集成不会消失。这意味着你需要一个集成软件如ESB来满足你所有的企业集成需求。
  • 所有的业务功能需要通过API管理技术暴露为API。
  • 微服务之间的交互要通过网关来支持。
  • 微服务之间的服务编排对某些业务场景是必须的,可以通过在一个新的微服务内或者在网关层来实现编排工作。

原文链接:Microservices in Modern Enterprise Architecture(翻译:姚洪)

原文发布时间为:2016-08-24

本文作者:姚洪

原文标题:现代企业架构下的微服务

时间: 2024-10-28 22:24:45

现代企业架构下的微服务的相关文章

Java微服务开发指南 -- Java环境下的微服务

Java环境下的微服务 本文涉及的内容,能让你学到什么?     本书适用于开发微服务的Java开发人员和架构师.我们在开始介绍微服务架构前,先讲述一些抽象的基本概念.不幸的是,使用新技术并不能神奇地解决分布式系统问题.但是我们通过一些做的很好的公司,它们是如何使用微服务来进行构建的,包括文化.组织结构和市场压力.然后我们深入了解几个Java微服务框架,附带的源代码反馈可以在GitHub上找到.我们会讨论有关部署.集群.故障转移以及Docker和Kubernetes在这些领域是如何解决这些问题.

微服务实践(七):从单体式架构迁移到微服务架构

本文讲的是微服务实践(七):从单体式架构迁移到微服务架构,[编者的话]这是用微服务开发应用系列博客的第七篇也是最后一篇.第一篇中介绍了微服务架构模式,并且讨论了微服架构的优缺点:接续文章讨论了微服务架构不同方面:使用API网关,进程间通信,服务发现,事件驱动数据管理以及部署微服务.本篇,我们将探讨将应用从单体式架构迁移到微服务架构需要考虑的策略. 希望读者通过本系列文章对微服务优缺点有一个比较好的理解,以及何时使用这种架构.也许微服务架构比较适合你的应用.也许你正在开发一个大型.复杂单体式应用,

微服务架构设计 (六): 微服务间的共享的管理

在微服务的架构下, 产品或许会有上百个或上千个微服务.所以, 当这些上百个或上千个微服务, 同时都依赖于某个库 (Library) 时, 则当此共享的库, 即使只是针对某个微服务做些很少量的修改, 也可能会对其他上百个或上千个微服务, 造成不可预期的影响. 但在实际的项目中, 产品中的微服务又无法避免的会对某些库 (Library) 产生依赖; 共享某些库 (Library). 所以, 架构师必需要知道要如何管理微服务间的共享? 微服务会形成共享的原因, 主要是来自于: 微服务共同继承于某个抽象

DotNET企业架构应用实践 - 用服务定位器(SL)完成服务的多种实现的统一调用

        前面的文章服务定位器(SL)与AgileEAS.NET中的实现介绍了服务定位器的一些概念.应用场景与AgileEAS.NET平台中SL的实现,本文是这骗文件的一个例子与Demo,详细的演示SL在应用开发中的使用.         下面我说开始例子,假设有这么一个应用场景,我们需求一个Hello服务,并且需要在XML WebService..NET Remoting和本地同进程中三种不同环境的应用,也就是说,这个服务可能会有三中实现,具体使用那一个,在应用过程中决定,我先贴个简单的

微服务实战:从架构到发布(二)

引言:上篇文章介绍了微服务和单体架构的区别.微服务的设计.消息.服务间通信.数据去中心化,本篇会继续深入微服务,介绍其它特性. 治理去中心化 通常"治理"的意思是构建方案,并且迫使人们通过努力达到组织的目标.SOA治理指导开发者开发可重用的服务,以及随着时间推移,服务应该怎么被设计和开发.治理建立了服务提供者和消费者之间对于服务的协定,告诉消费者能从服务提供获取到什么样的支持. SOA中有两种常见的治理: 设计时的治理-定义和控制服务的创建.设计和服务策略的实施. 运行时的治理-确保执

几种常见的微服务架构方案——ZeroC IceGrid、Spring Cloud、基于消息队列、Docker Swarm

微服务架构是当前很热门的一个概念,它不是凭空产生的,是技术发展的必然结果.虽然微服务架构没有公认的技术标准和规范草案,但业界已经有一些很有影响力的开源微服务架构平台,架构师可以根据公司的技术实力并结合项目的特点来选择某个合适的微服务架构平台,以此稳妥地实施项目的微服务化改造或开发进程. 本文选自<架构解密:从分布式到微服务>. 本文盘点了四种常用的微服务架构方案,分别是ZeroC IceGrid.Spring Cloud.基于消息队列与Docker Swarm. ZeroC IceGrid微服

微服务、容器与持续交付

本文件的是微服务.容器与持续交付[编者的话]就像木炭.火硝和硫磺遇到了一起.当微服务.容器和持续交付遇到了一起,这注定会掀起一场变革. 微服务 如果非要给微服务找一个理由,单一职责就足够了.我们把因相同原因而变化的东西聚合到一起,而把因不同原因而变化的东西分离开.我们称之为单一职责原则SRP. 尤其是大型和长期运营的项目群,随着时间的推移,需求一定是不断增加和变更的.但我们不希望掉进"焦油坑".我们希望我们的项目群是符合"开闭原则"的.在某个时期我们寄希望于一个统一

技术干货|如何在微服务架构下构建高效的运维管理平台?

黎明带领团队自主研发了全栈DevOps运维管理平台-EasyOps,是目前行业领先的智能化运维管理平台.作为前腾讯运维研发负责人,黎明主导了多个运维系统研发舆情监控.大数据监控平台.CMDB.实时日志分析平台.织云.客户端体验监控等. 本文内容有三点: 1.微服务架构特点及其传统巨石架构的差异,以及传统运维工具面临的挑战: 2.面向微服务的运维平台架构: 3.运维平台微服务进化. 一. 微服务架构与巨石架构的差异 "微服务"与"巨石架构"两者并非对立,而是分别针对不

通过Ruby on Rails和docker构建微服务架构之入门教程

说到时下的架构,免不了会涉及到微服务.而谈到微服务架构,又跟容器和Docker技术脱不了关系.虽然容器和Docker并不完全是一回事,但两者是密不可分的,而且二者之间也有共同之处:在大型复杂应用的构建和运营方面,二者都可以大大提高企业的效率.   微服务可不像一般的应用,可以通过apt-get工具进行安装,大家可能会问了:我们该如何才能像安装应用一样实现这种服务呢?在很大的程度上,这个问题的答案是否定的,我们无法轻松实现这种服务.更准确的说,至少目前我们还无法实现.在一个系统中,最难修改的就是架