[服务器架构]微服务的深入思考

标签: 服务器 架构 微服务 | 发表时间:2015-11-09 19:26 | 作者:abv123456789
出处:http://blog.csdn.net
微服务有且仅有一种非常专项的功能,通过远程API来提供系统其余功能。举个例子:试想一下仓库的管理系统,这样的系统中微服务可能提供的一些功能有: 
  • 接收库存
  • 计算新的库存该存到什么地方
  • 计算在仓库内将库存运往正确放置点的路线
  • 为仓库员工分配运送路线
  • 接收订单
  • 计算仓库内指定一组订单的拣货路线
  • 为仓库员工分配拣货路线

以上这些功能(可能还会有更多)都是由单个微服务实现的。每个微服务都有单独的运行线程,并且可以独立于其他微服务进行部署。同样每个微服务都有自己的专用数据库,尽管每个微服务都会与其他微服务协作与沟通。

一个系统中的不同微服务完全有可能在不同的平台上实现,一些可能在.NET上,另外一些在Erlang,其他的在Node.js上。只要能协调多语言的问题,各个微服务彼此正常沟通,就能奏效。HTTP是良好的沟通选择:上面所有提到的平台,还有很多其他平台都能很好的处理HTTP。当然也有符合微服务沟通规则的其他技术:例如一些队列、一些服务总线还有一些二进制协议。在这些技术当中,HTTP可能是支持最广泛的,相当容易理解,而且就像万维网所展示的那样很好用,总体来说是很好的方案。 

再次以仓库系统为例:该系统的一个微服务是分配拣货路线微服务。图一展示了“分配拣货路线微服务”从另一个协作微服务收到的请求:为指定员工设定了下一次的拣货路线。分配拣货线路微服务必须为员工找到合适的线路,而另一个微服务则完成计算最优路线的工作,分配拣货路线微服务只需收到拣货路线通知并确定如何为雇员分配路线。在分配拣货路线的微服务中,收到请求——分配指定员工的拣货路线,搜索数据库,找到合适的拣货路线,并从中选择一个返回给微服务调用。 

 

微服务架构是什么? 

微服务是一种架构类型,属于轻量级的面向服务体系架构,这些服务都是严格专注于执行同一件事并把它做好。

使用微服务作为主要架构类型的系统是一个拥有大量协调微服务的分布式系统,每个微服务分管自己的进程。由于微服务之间紧密协作,每个微服务只提供拼图的一小块,而系统做为完整的作品存在。协作时,各服务彼此通过一个不绑定具体平台的轻量级媒介进行沟通,比如.NET,Java或者Erlang。如前所述,本书中所有微服务之间的沟通都是通过HTTP的,不过还有其他可选方案,比如队列、总线或者类似Thrift的二进制协议。 

在构建与维护复杂的服务器端软件系统时,微服务架构类型迅速流行起来。可以想见,这样一来:在传统的面向服务方法和整体架构(monolithic architectures)中,微服务都有大量潜在好处。在运作良好的前提下,微服务在可塑性、可扩展性与弹性方面都具有优势,并允许使用者只花费很短的时间就实现从开始到生产环境部署的过程。 

微服务特性 

虽然已经说了这么多,不过定义还很模糊。为了缩小微服务的界定范围,我们先来考察一下微服务的特性。在笔者理解中,微服务这个术语的特性是: 
1. 负责单个功能 

2. 单独部署 

3. 包含一个或多个进程 

4. 拥有自己的数据存储 

5. 一支小团队就能维护几个微服务 

6. 可替换的 

这张特性列表不但帮助识别微服务,还能够在发挥微服务优势(一个拥有可塑性、可扩展性与弹性的系统)的前提下协助界定与执行该服务,依次看下去。 

负责单个功能 

微服务在整个系统中只负责单个功能。这句话分解来说包含两部分内容:第一,微服务只有单个责任;第二,负责的是功能。单一责任原则有几种描述,其中一个传统的描述是: 
引用

“当需要修改某个类的时候原因有且只有一个("There should never be more than one reason for a class to change.")” -- Robert C. Martin SRP: 单一责任原则 

尽管这种说法特别提到了“类”,这一原则却不只适用于面向对象语言的类层面。通过微服务,这里在服务层面运用单一责任原则。另一种较新的说法也是描述单一责任原则的: 
引用

聚合因同一理由变化的东西,分离因不同理由而变化的东西。("Gather together the things that change for the same reasons. Separate those things that change for different reasons.")-- Robert C. Martin单一责任原则 

这一原则适用于微服务:微服务应当正好实现一个功能。微服务必须只在功能改变时才跟着改变。此外,应当努力让微服务完全实现相关功能,这样在功能改变时微服务也得跟着改变。 

微服务系统的一个功能可能意味着几件事。首先,功能可能是业务方面的。业务功能就是系统所完成的、对系统的目的有贡献的事情——比如持续追踪用户的购物车或者计算价格。梳理一个系统拥有的独立业务功能有一个好办法,就是使用Domain Driven Design。第二,有时候功能可以是多个其他微服务需要利用的技术功能——例如集成到一些第三方系统中。技术功能并非是将系统分解成微服务的主因,而是由于微服务执行业务功能需要同样的技术能力而导致的结果。 

独立部署 

每个微服务都应当是单独部署的。也就是说:当你改变一个特定的微服务时,需要能够将微服务的变更部署到生产环境中,而无需部署或触及系统的其他部分。事实上,系统中的其他微服务应当在改动的微服务部署之时,还有新版本部署完成之后继续持续运行。 

试想一下电子商务网站:每次购物车微服务发生改变时,都应当能立即进行部署。同时价格计算微服务、推荐微服务、产品目录微服务等等应当继续运行并满足用户的请求。 

能够单独部署每个微服务非常重要,原因有好几个。其中一点是,在一个微服务系统中有很多微服务,每个微服务都会与其他几个相协作。各部分的开发工作同时完成,或者很多微服务并行。如果需要按同一步调部署所有或者很多微服务的话,管理部署很快就会变得捉襟见肘,特别是经常会导致高风险部署,这是我们很希望避免的。相反我们希望能够对每个微服务进行小变更部署,这样风险会更低。 

能够在系统的其他部分继续正常运行的时候部署单个微服务,构建过程必须牢记这一点:每个微服务必须打包到不同的构件或程序包中。同样地,部署过程本身还必须支持在其他微服务继续运行之时,独立部署变更的微服务。比如,每次将微服务部署到服务器的过程中,为了减少停机时间可以使用滚动部署的办法。 

微服务互动的方式也受到期望独立部署的影响。改变微服务接口必须在大多数情况下向后兼容,这样其他现有的微服务就可以继续按照与旧版本融合的方式与新版本集成了。此外,微服务互动的方式必须有弹性,每个微服务必须在其他微服务偶尔出错时继续保持最佳运行状态。一个微服务出错——比如因为部署时的短暂停机——必须不影响其他微服务运行,只是造成功能缩减或者进行时间稍长。 

包含一个或多个进程 

一个微服务由一个或多个进程组成,这个特性有两面性。首先,每个微服务独立于其他微服务运行;其次,每个微服务可以拥有不止一个进程。 

某微服务独立运行,是由于希望保持每个微服务尽可能独立于其他微服务继续运行。此外,为了独立部署微服务,那个微服务不能按照其他微服务的方式来运行。再用购物车微服务来举例:如果按照与产品目录微服务相同的方式运行,购物车代码可能对产品目录代码产生负面影响,这代表着购物车微服务与产品目录微服务之间紧密却不受欢迎的耦合。 

 

现在思考一下部署购物车微服务的新版本情况。要么得重新部署产品目录微服务,要么就得有某种动态代码加载功能,来替换正在运行中的购物车代码。前一个选项与微服务独立部署的原则完全相违背,后一个选项太过复杂而且起码有由于部署购物车微服务而造成产品目录微服务停机的风险。 

每个微服务可能包含不止一个进程,表面来看可能令人惊讶,毕竟这里尝试让每个微服务尽可能简单好控制,那么为什么要自找麻烦拥有不止一个进程呢?用电子商务网站做个比方:执行推荐算法会在电子商务网站上展示推荐选项,这些算法都在这个微服务所属的进程中运行,还存储了提供推荐需要的数据。这个数据可能存储在硬盘文件里,不过更有可能存在数据库里,在第二个进程中运行的数据库也属于这个微服务。一个微服务通常拥有2个或以上进程的需求,就是因为微服务需要实现所需要的一切,以提供包含诸如数据存储还有后台处理之类的功能。 

拥有自己的数据存储 

一个微服务包含数据存储,在该进程中存储所需的数据,正是由于我们希望微服务的范围是一个完整的功能。大多数业务功能需要一些数据存储,例如对于产品目录微服务来说,每个产品的信息需要存储下来。为了保持产品目录微服务与其他微服务的松散耦合性,存储的产品信息数据完全包含在产品目录微服务之中。由产品目录微服务确定何时、如何存储产品信息。其他微服务——比如购物车微服务——只能通过产品目录微服务的接口来访问产品信息,而永远不能直接访问产品目录存储。 

 

每个微服务包含自己的数据存储,这开启了根据每个微服务需求,为不同微服务使用不同数据库技术的可能性。产品目录微服务可能使用SQL服务器来存储产品信息,而购物车微服务可能用Redis来存储每个用户的购物车信息,推荐微服务则使用Elastic Search索引来提供推荐服务。为每个微服务所选择的数据库技术是执行的一部分,对其他微服务来讲是隐藏的。将数据库技术与每个微服务需求进行混合配对的好处在于,每个微服务可以使用最适合的数据库。对开发时间、性能和可扩展性很有好处,不过也带来了成本问题。数据库技术上非常复杂,学习使用和在生产环境上运行一个可靠的数据库都不容易。为微服务选择数据库信息时,应当考虑取舍的问题。不过也要记住,由于微服务拥有自己的数据存储,稍候切换到另一个数据库也是可行的。 

小团队就能维护 

到现在本文并未讨论太多微服务的规模问题,虽然微服务中的“微”暗示着这些服务规模很小。但这里并不认为讨论微服务应当有几行代码,需求/用例有多少或者应当执行的功能点有几个这些有什么意义。所有这些取决于微服务所提供功能的复杂性。真正有意义的是考虑维护微服务的工作量。指出微服务规模大小的一条经验法则是:一个5人小团队就应当能够维护几个或者更多的微服务。维护一个微服务包括保持其正常运行并达成目标:开发新的功能、从发展到过大规模的微服务中分解出新的微服务、监控测试与修复bug及其他。考虑到一个小团队应当能够完成几个微服务的所有这些工作,你应当对典型的微服务规模有概念了。 

可替换的 

一个微服务是可替换的,代表着它可以在合理的时间框架内从头重写。也就是说,维护该微服务的团队可以决定用全新的实现来替代现有的,并且不会打乱正常工作的进程。这条特性也是微服务规模的一条约束:如果一个微服务成长地太大,替代成本就会过高,只有保持小型才能让重写比较现实。 

为什么团队会决定重写微服务?一个原因可能是代码太乱,另一个原因是微服务不能在生产环境中运行良好。尽管这些情况并非所愿,却出体现了微服务的优势。即便努力构建微服务,时间造成的需求变更可能促使现有的实现方式无法满足需求而需要变更。而且随着时间过去,代码可能会由于初始设计周折太多而变成一团乱麻。性能要求可能会需要大幅提升,而现有设计无法满足。如果一个微服务小到在合理时间框架内便能重写,偶尔出现这些情况都是ok的。了解现有实现所有知识的同时,再结合新需求考虑,就能简单地完成重写工作。 
作者:abv123456789 发表于2015/11/9 11:26:26 原文链接
阅读:0 评论:0 查看评论

相关 [服务器 架构 微服务] 推荐:

[服务器架构]微服务的深入思考

- - CSDN博客推荐文章
微服务有且仅有一种非常专项的功能,通过远程API来提供系统其余功能. 举个例子:试想一下仓库的管理系统,这样的系统中微服务可能提供的一些功能有: . 计算新的库存该存到什么地方. 计算在仓库内将库存运往正确放置点的路线. 计算仓库内指定一组订单的拣货路线. 以上这些功能(可能还会有更多)都是由单个微服务实现的.

谈微服务架构

- - 人月神话的BLOG
其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是本质还是紧耦合的,这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

面向服务与微服务架构

- - CSDN博客推荐文章
最近阅读了 Martin Fowler 和 James Lewis 合著的一篇文章  Microservices, 文中主要描述和探讨了最近流行起来的一种服务架构模式——微服务,和我最近几年工作的实践比较相关感觉深受启发. 本文吸收了部分原文观点,结合自身实践经验来探讨下服务架构模式的演化. 面向服务架构 SOA 思想概念的提出已不是什么新鲜事,大概在10年前就有不少相关书籍介绍过.

微服务架构实践感悟

- - mindwind
从去年初开始接触微服务架构的一些理念,然后到今年开始实施系统第四个大版本的架构升级决定采用这套架构理念. 最近关于微服务架构的讨论还是多起来,因为国外一些著名互联网公司(如:Amazon、Netflix 等)从实践中摸索出了一套新的大型系统架构方法论,并取得了成功,树立了很好的示范,然后这套方法论渐渐就被一些技术理论派 人士命名为微服务架构(Microservices).

微服务架构成功之路

- - CSDN博客推荐文章
本文来源于我在InfoQ中文站翻译的文章,原文地址是:http://www.infoq.com/cn/news/2015/07/success-of-microservices. 近年来,在软件开发领域关于微服务的讨论呈现出火爆的局面,有人倾向于在系统设计与开发中采用微服务方式实现软件系统的松耦合、跨部门开发;同时,反对之声也很强烈,持反对观点的人表示微服务增加了系统维护、部署的难度,导致一些功能模块或代码无法复用,同时微服务允许使用不同的语言和框架来开发各个系统模块,这又会增加系统集成与测试的难度,而且随着系统规模的日渐增长,微服务在一定程度上也会导致系统变得越来越复杂.

微服务架构-模块迁移

- - 人月神话的BLOG
对于遗留的单体应用,要进行微服务架构的改造往往比一个全新应用基于微服务架构实现更加困难. 对于单体应用的微服务架构改造,最常见的方式仍然是将低耦合的模块逐步迁出. 下面以一个采购系统中招投标模块迁出为例进一步思考单体应用的微服务架构改造步骤. 在整个模型中我们将模型进行简化,当迁出一个功能模块进行微服务化的时候,首先要考虑的就是对该模块进行集成架构分析,考虑该模块和外围的集成情况,其次才是考虑该模块内部的私有数据.

SOA和微服务架构沟通(2.8)

- - 人月神话的BLOG
今天在广州交流SOA和微服务架构,特对关键内容做简单记录. 对于SOA和微服务架构的区别,在知乎一个回答里面我已经进行了详细的说明,即微服务架构强调的第一个重点就是 业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用. 这些小应用之间通过服务完成交互和集成.

图解Flickr的服务器架构

- Adam - 服务器运维与网站架构|Linux运维|互联网研究
前Flickr的架构师  Cal Henderson,在 Flickr: Web Services 这个PPT中,有对其架构比较全面的阐述. Flickr运维团队的John Allspaw,有两个讲LAMP的幻灯,Hardware Layouts for LAMP Installations 和  capacity planning for LAMP,但应该是Flickr架构演进和运维的一些经验总结,其中也透露一些服务器架构.

Google服务器架构图解简析

- Version - 服务器运维与网站架构|Linux运维|互联网研究
Google,无疑是互联网时代最闪亮的明星. 截止到今天为止,Google美国主站在Alexa排名已经连续3年第一,Alexa Top100中,各国的Google分站竟然霸占了超过20多个名额,不得不令人感叹Google的强大. 不论何时,不论何地,也不论你搜索多么冷门的词汇,只要你的电脑连接互联网,只要你轻轻点击“google搜索”,那么这一切相关内容google都会在1秒钟之内全部搞定,这甚至比你查询“我的文档”都要快捷.