转载

一体化架构和微服务架构

【译者的话】otto.de是德国的一家网上购物网站,本篇前半部分主要介绍了几个系统架构以及它们的优缺点,后半部分主要讲解otto.de的微服务架构。

在我们开始开发otto.de网上商店时,我们选择了分布式垂直架构。之前的工作经验告诉我们,一体化架构(monolithic architecture)不能够满足不断增长的需求。爆发式增长的数据,持续提高的负载和对系统的扩展,所有的这些强迫我们去重新思考网站的架构。

这篇文章将会描述我们的解决办法,还有我们这么做的原因。

一体化(Monoliths)

在项目刚开始的时候,团队通常会考虑使用什么编程语言和合适的架构。当谈到服务端应用时,Java和Spring框架,Ruby on rails或者类似的框架通常会成为团队的选择。

选择了语言和框架后,经过一段时间的开发,一个简单的应用诞生了。与此同时,一体式架构(macro-architecture)毫无争议的成为了团队的选择。但是,这种架构的缺点也渐渐地浮出了水面:

  • 它导致了重量级微架构(a heavyweight Micro Architecture)
  • 负载均衡限制了应用的可扩展性
  • 系统的可维护性受到影响,尤其是那些大型应用
  • 零停机部署(Zero downtime deployment)变得非常的困难,尤其是那些有状态的应用(stateful application)
  • 多个团队开发效率低,并且需要额外的协调

一体化架构和微服务架构

当然,这并不是说一个新的应用一开始就变得巨大而混乱。在最开始的时候,新应用结构清晰,简单易懂,可扩展性也高,它能够很轻松的解决需求问题。在接下来的一段时间中,越来越多的代码被编写。为了应对日益增长的复杂度,系统被分层,抽象,模块,服务和框架被引入到系统中,最终变成了我们看到的样子。

即便是中型的应用(比如说一个50000的Java应用),一体化架构也会渐渐地变得令人讨厌,更不用说那些对扩展性要求较高的应用了。

最终,曾经轻量简洁的应用将会变成下一代开发者的噩梦。

分而治之

问题的关键在于,如何避免这种类型的开发,并且将轻量应用好的那部分保留下来。换句话说,我们如何能够获得一个可持续发展的架构,这个架构在多年之后依旧能够让开发者保持高效开发。

在软件的开发过程中,有许多关于结构化代码的概念:函数,方法,类,库,框架等等。这些概念并不是程序运行所必须的,发明他们的原因是为了帮助开发者更好的理解他们的应用。

目前软件开发者已经理解了这些概念,一个问题接踵而来:为什么这些概念仅仅被应用于一个软件?是什么阻碍我们将应用拆分成多个低耦合的部分?

有三件事情我们需要牢记在心:

  • 康威定律:软件开发最开始时仅有一个团队,根据康威定律,因此会产生一个应用。(译者注:可以参考 图片 理解)
  • 初始消耗:部署应用,并让它运行起来似乎是一个非常简单的任务。实际上,你需要建立并管理VCS代码库,编译文件,构建管道,用于部署的程序,硬件,虚拟机,日志文件,监控软件等等。所有的这些都需要花费一定的时间去处理。
  • 操作的复杂性:大型分布式系统比一个小型的负载均衡集群更难操作。

如果我们放手不管,由多个小型模块组成的系统并不会出现,一个巨大而混乱的系统将会取而代之。这时候,致命的问题已然出现,然而悔之晚矣。

正常情况下,一个系统是否需要被扩展,是否需要处理巨大的代码库在初期是非常清楚的。然后当你遇到以上提到的障碍,你要么没尝试解决他们,要么只能沉沦在无尽的苦果中。

在OTTO,在最开始的时候就花费了大量时间去建立4个跨职能的团队,根据前面提到的康威定律,一个项目属于4个团队,最终就能产生一个由4模块组成的应用,这样就避免了一体化应用的诞生。

因为我们之前操作过大型的一体化应用,操作的复杂性对于我们似乎是一个可以被解决的问题---操作200个一体化应用和操作200个更小型的系统没有太大的区别。

初始消耗可以通过标准化和自动化来克服。因为我们没有提到云服务,你还需要做相关的基础操作来启动自动化服务。虽然有些麻烦,但做过一次后,一切将自动化,你会获得巨大的便利。

可扩展性

如何将一体化应用转变为由多个小模块组成的应用?首先,让我们仔细想想一个应用能够从哪些维度进行扩展。

纵向分解(Vertical Decomposition)

纵向分解是一个非常自然而通用的方法,以至于常常被开发者所忽略。相比于把所有的功能集中到单一的应用中,我们将应用分解成了多个小模块,它们相互独立,互不影响。

一体化架构和微服务架构

我们可以根据业务域来分解系统。举个例子来说,在otto.de我们就讲网上商城分解成了11个不同的垂直模块:后勤办公室,产品,订单等等。

每一个垂直模块属于一个单一团队,它们有独立的前端,后端和数据存储。在模块之间共享代码是严令禁止的。当然,在特殊的情况下,如果我们需要分享代码,我们会建立一个开源的项目来解决该问题。

因此,每个垂直模块是一个独立自主的系统,就像Stefan Tikov在Substainable Architecture中提到的那样。

分布式计算

一个垂直模块依旧可能成为一个相对大型的一体化应用,因此我们需要继续对垂直模块进行拆分。一种方法是将一个垂直模块分解成更多的垂直模块,另外一种方法是通过分布式计算将系统分解成多个模块,不同的是这些模块运行在他们自己的进程中,并且通过REST来传递信息。

一体化架构和微服务架构

在这种情况下,应用不仅仅被垂直分解,同时还会被水平分解。这种架构中,请求到达应用后,对请求的处理会被分布于多个模块中,然后每一模块产生的结果汇总成一个响应,发送回请求者。

这些模块并不会共享一个数据库架构,因为这样做会导致模块间的紧密耦合:数据结构的改变会使得一个模块不能够被独立的部署。

分片

当系统需要处理大量的数据,或者当一个分布式的应用被操作时,分片是很恰当的选择。比如说,分片非常适合向全球范围提供服务的应用。

一体化架构和微服务架构

因为我们暂时没有利用到分片这个概念,在这篇文章就不再详细描述了。

负载均衡

每当服务器承受不了巨大的负载压力时,负载均衡就会容重登场。通过对一个应用拷贝多次,同时利用负载均衡器将负载分解来缓解压力。

一体化架构和微服务架构

在负载均衡中,不同实例的应用通常会分时使用同一个数据库,数据库因此成为了系统的瓶颈,但是我们可以通过制定良好的扩展策略来避免这个问题。相比于关系数据库,NoSQL能够很好的处理扩展性的问题,这也就是NoSQL能够在软件世界中占据一亩三分地的原因之一。

最大的可扩展性

所有以上提到的办法能够组合在一起,能够达到任何级别的可扩展性。

一体化架构和微服务架构

当你没有相应的需求时,组合的结果会变得有点太复杂。幸运地是,开发者并不需要在一开始的时候就制定庞大的计划,相反,他们可以循序渐进,一步步朝着目标架构前进。

举个例子来说,在otto.de,架构一开始是4个垂直模块加上负载均衡,在过去的三年里,产生了更多的垂直模块。在此期间,某些模块变得非常的巨大笨重。因此,我们引入了微服务架构,同时通过扩展垂直模块来建立分布式计算。

微服务(Microservices)

微服务最近变得非常的流行。微服务是一种架构风格,它能够根据业务域将系统分解成多个细粒度,独立的模块。

在这种情况下,微服务可以是一个小的垂直模块,或者是分布式计算机构中的一个服务。与传统方法的不同之处在于应用的大小:一个微服务仅仅实现了一个业务域中的几个功能,它结构清晰,一个开发者能够很轻松的掌握它。

一个微服务非常的小,因此多个微服务能够运行在单一的服务器上。我们对“Fat JARs”有丰富的经验,通常能通过执行java –jar <file>来执行它们。如果需要的话,也能开启一个Jetty或者类似的服务器。

为了简化不同微服务的部署和操作问题,每一个服务器运行在独立的Docker容器中。

REST和微服务架构是一个很好的组合,它适合于构建大型的系统。一个微服务可以负责提供REST资源,超媒体(hypermedia)可以用来解决服务发现的问题,在涉及到接口的版本控制,服务部署独立性的情况下,媒体类型(media type)有很大的帮助。

总而言之,微服务架构有许多的好处,比如说:

  • 在微服务架构下进行开发是非常有趣的:每几周或者几个月,你就可能开始一个新的开发项目。
  • 由于微服务非常小,微服务架构不需要重量级框架和过多的模板代码。
  • 他们能够被独立的部署。因此持续交付或者持续部署变得非常的简单。
  • 微服务架构能够支持多个独立的团体同时开发。
  • 开发者能够为每一个服务选择最恰当的开发语言。不用担心对项目产生影响,开发者可以尝试新的语言或者框架。但是需要注意,这并不意味这你能够随意行使这项权利。
  • 因为微服务足够小,只需消耗较少的资源就能将他们替换成新的项目。
  • 这种架构的可扩展性相比于一体化架构显得非常的好,每一个服务都能被独立的扩展。

微服务架构遵守敏捷开发的原则。一个不能完全满足用户的新特性不仅可以被迅速的创建,而且还能够被快速的销毁。

宏架构和微架构(Macro- and Micro-Architecture)

在微服务架构中,哪一部分将难以改变?内部模块的扩展已经不再是关键问题,最难以改变的事情是有关微服务架构的决定,比如说如何将微服务整合到系统的方法,或者模块间传输信息协议的选择。

因此,otto.de严格区分了微架构(micro-architecture)和宏架构(macro-architecture)。微架构都是关于垂直架构或者微服务架构的内部结构,并且全部交由各自的团队全权处理。

但是,明确宏架构的大体方向是有价值的:

  1. 垂直分解:系统被分割成多个垂直模块,每一个模块完全属于一个特定的团队。模块与模块之间的信息传递禁止在用户请求的过程中进行,而必须在后台执行。
  2. RESTful架构:不同服务之间的信息传递和整合只通过REST来执行。
  3. 零分享架构:服务间不会通过共享可变状态(mutable state)来进行信息交换或者分享信息。没有HTTP sessions,没有中央数据存储中心,没有共享代码。但是多个服务的实例之间有可能共享一个数据库。
  4. 数据管理:对于每一个数据节点,只有一个系统负责管理。其他的系统只能通过REST API读取数据,然后将需要的数据拷贝回自己的数据库。

我们的架构已经熬过了一轮软件开发周期,与此同时,我们开始标准化微服务使用的方式。

集成

目前为止,我已经详细说明了许多有关系统分解的内容。但是,用户体验是我们的系统的最终目标,我们希望我们的应用保持一致性,感觉就像是一个整体。

因此,问题来了:我们如何能够集成一个分布式的系统,同时让用户意识不到我们架构的分布特性。

超链接

对于前端集成,最简单的办法就是使用超链接。

每一个服务负责不同的页面,页面的导航通过链接来实现。

一体化架构和微服务架构

AJAX

使用AJAX的目的也很明显,它能够通过Javascript重新加载页面的不同内容,并且将他们整合在特定的页面。

主要注意的是,服务之间涉及到的依赖非常的小,服务互相之间需要对使用的URL和媒体类型(media type)保持一致性。

一体化架构和微服务架构

资源服务器(Asset Server)

当然,图片在不同页面的显示也需要保持一致性。除此之外,分布式的服务需要对他们各自的Javascript库和版本保持一致。

为了保持一致性,在我们的系统中,静态资源,比如说CSS,JS和图片都是通过一个中央资源服务器来进行传输。

在垂直架构,共享资源的部署和版本控制是一个完全不同的话题,这需要一篇独立的文章来详细解释。在这里我们不做过多解释,我们只需要记住,共享资源的同时保持服务独立是具有非常大的挑战性。

Edge-Side Includes

有一种不太知名的方法,它能整合不同服务的资源到同一个站点。这种方法我们称之为Server-Side Includes或者是Edge-Side Includes。大多数的Web服务器或者反向代理都只支持这个功能。

这项技术非常的简单:一个服务插入插入一条带有URL的包含语句(include statement)。然后这个URL会被web服务器或者反向代理解析,代理根据URL获取到一个响应,然后用这个响应代替页面中的包含语句。

在我们的商城中,每一个页面都包含了来自搜索&导航服务(SAN)的导航信息:

<html>
...
<esi:include src=“/san/...“ />
...
</html>

反向代理(我们使用了Varnish)解析了页面,然后将URL分解出来,SAN根据URL提供相应的HTML片段。

然后Varnish代理用这个HTML片段取代包含语句,并将重新生成的页面发送回用户。

在这种方式下,用户根本意识不到页面是由多个来自不同服务的片段组成的。

数据拷贝(Data Replication)

以上提到的技术仅仅解决了前端集成问题,现在我们来谈谈服务端集成。不同的服务之间需要共同的数据,但是他们又不能共享同一个数据库,因此我们想了一些办法来处理这个问题。

数据拷贝就是一个办法。比如说,其他的服务需要关于产品的数据,它们就会定期的向负责产品数据的垂直模块(Product)请求数据,这样产品数据的更新能够很迅速的被其他服务检测到。

我们没有使用任何的消息队列来向客户端推送(push)数据。相反的,每当服务需要更新数据时,它们会轮询(poll)Atom Feed。

值得一提的是,某些不好的事情必须牺牲服务的可用性来避免,我们在开发过程中不得不面对这个矛盾。

没有远程服务调用(NO Remote Service Calls)

理论上来说,在某些情况下,我们可以避免数据的拷贝,这样服务就能够同步使用其他的服务了。一个购物篮并不需要保存额外的产品信息,相反它可以直接向产品模块请求数据。

我们并没有这么做,为什么呢?

  • 当一个系统的主要功能依赖于其它系统时,系统的可测试性受到影响。
  • 一个缓慢的服务会影响到其它系统的请求,当请求越多,雪球越滚越大,最终影响到了整个系统的可用性。
  • 系统的可扩展性受到了限制。
  • 独立的服务部署变得非常的困难。

我们长期和垂直架构打交道,我们非常明确的知道,在早期的时候,严格的界限会使得微服务的开发,测试,迁移变得更加独立,方便。

经验教训

按照以上罗列的办法,经过三年的工作后,我们变得经验丰富。

回顾往事,如果我早点做这些事情,我们的一体化系统会变得更加的精细。现在,otto.de的未来属于微服务。

原文链接: On Monoliths and Microservices (翻译:杨润青)

===========================

译者介绍

杨润青,90后博士僧,研究方向是网络和信息安全。

正文到此结束
Loading...