时下流⾏devops关键词：分布式架构、⼀体化架构和微服务架 构
技术趋势关键词：分布式架构+微服务架构（针对移动互联⽹）+⼀体式架构（前两者结合+UI等敏捷开发）
【译者的话】otto.de是德国的⼀家⽹上购物⽹站，本篇前半部分主要介绍了⼏个系统架构以及它们的优缺点，后半部分主要讲解otto.de的微服务架构。 在我们开始开发otto.de⽹上商店时，我们选择了分布式垂直架构。之前的⼯作经验告诉我们，⼀体化架构（monolithic architecture）不能够满⾜不断增长的需求。爆发式增长的数据，持续提⾼的负载和对系统的扩展，所有的这些强迫我们去重新思考⽹站的架构。
这篇⽂章将会描述我们的解决办法，还有我们这么做的原因。
⼀体化（Monoliths）
在项⽬刚开始的时候，团队通常会考虑使⽤什么编程语⾔和合适的架构。当谈到服务端应⽤时，Java和Spring框架，Ruby on rails或者类似的框架通常会成为团队的选择。
选择了语⾔和框架后，经过⼀段时间的开发，⼀个简单的应⽤诞⽣了。与此同时，⼀体式架构（macro-architecture）毫⽆争议的成为了团队的选择。但是，这种架构的缺点也渐渐地浮出了⽔⾯：
当然，这并不是说⼀个新的应⽤⼀开始就变得巨⼤⽽混乱。在最开始的时候，新应⽤结构清晰，简单
易懂，可扩展性也⾼，它能够很轻松的解决需求问题。在接下来的⼀段时间中，越来越多的代码被编写。为了应对⽇益增长的复杂度，系统被分层，抽象，模块，服务和框架被引⼊到系统中，最终变成了我们看到的样⼦。 即便是中型的应⽤（⽐如说⼀个50000的Java应⽤），⼀体化架构也会渐渐地变得令⼈讨厌，更不⽤说那些对扩展性要求较⾼的应⽤了。
最终，曾经轻量简洁的应⽤将会变成下⼀代开发者的噩梦。
分⽽治之
问题的关键在于，如何避免这种类型的开发，并且将轻量应⽤好的那部分保留下来。换句话说，我们如何能够获得⼀个可持续发展的架构，这个架构在多年之后依旧能够让开发者保持⾼效开发。
节能玻璃贴膜在软件的开发过程中，有许多关于结构化代码的概念：函数，⽅法，类，库，框架等等。这些概念并不是程序运⾏所必须的，发明他们的原因是为了帮助开发者更好的理解他们的应⽤。
⽬前软件开发者已经理解了这些概念，⼀个问题接踵⽽来：为什么这些概念仅仅被应⽤于⼀个软件？是什么阻碍我们将应⽤拆分成多个低耦合的部分？
有三件事情我们需要牢记在⼼：
如果我们放⼿不管，由多个⼩型模块组成的系统并不会出现，⼀个巨⼤⽽混乱的系统将会取⽽代之。这时候，致命的问题已然出现，然⽽悔之晚矣。
正常情况下，⼀个系统是否需要被扩展，是否需要处理巨⼤的代码库在初期是⾮常清楚的。然后当你遇到以上提到的障碍，你要么没尝试解决他们，要么只能沉沦在⽆尽的苦果中。
在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读取数据，然后将需要的数据拷贝回⾃
⼰的数据库。
我们的架构已经熬过了⼀轮软件开发周期，与此同时，我们开始标准化微服务使⽤的⽅式。
集成
⽬前为⽌，我已经详细说明了许多有关系统分解的内容。但是，⽤户体验是我们的系统的最终⽬标，我们希望我们的应⽤保持⼀致性，感觉就像是⼀个整体。
因此，问题来了：我们如何能够集成⼀个分布式的系统，同时让⽤户意识不到我们架构的分布特性。
超链接
对于前端集成，最简单的办法就是使⽤超链接。
每⼀个服务负责不同的页⾯，页⾯的导航通过链接来实现。
墙体切割开门洞
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议