微服务介绍 已翻译 100%

oschina 投递于 2015/05/20 06:16 (共 20 段, 翻译完成于 05-23)
阅读 12886
收藏 177
14
加载中

这是一篇由 Chris Richardson 撰写的客座文章。Chris 是 CloudFoundry.com 的创始人,这是一个早期的用于 Amazon EC2 的 Java PaaS (Platform-as-a-Service平台即服务)。他现在为大型组织提供咨询服务,帮助他们提升开发和部署应用的能力。他还在有规律地写关于微服务的博客,博客地址:http://microservices.io

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

目前,微服务得到较多的关注:论文,博文,社交媒体上的讨论,还有会议报告。他们处于期望膨胀期的顶峰,快速地向着登上 Gartner 趋势报告前进。同时,在软件社区还有一群怀疑论者,他们无视微服务,认为它没什么新意。反对派们声称,这种想法就是 SOA 的马甲。但是,不管是大肆宣传还是怀疑主义,微服务架构模式具有明显的好处——尤其谈到敏捷开发和复杂企业应用交付的时候。

这篇博文是一个关于设计、构建和部署微服务的七部系列的第一部分。你将会了解到微服务的方法和它与传统的单一架构模式的对比。这个系列将会详细说明微服务架构的众多元素。你将会了解到微服务架构模式的好处和缺点,对你的项目是否有意义,和怎样应用它。

现在,我们先看看为什么你应该考虑使用微服务。

社会主义好
社会主义好
翻译于 2015/05/22 21:10
3

构建整体应用

假设你想要构建一个全新的打车应用与 Uber 和 Hailo 竞争。经过了一些预备会议和需求收集之后,你将会手工创建一个新的工程,或者使用 Rails、Spring Boot、Play 或 Maven 这类工具生成一个。这个新应用将会有一个模块化的六角形架构,就像下图这样:

Graph-01该应用的核心是服务模块、域对象模块和事件模块实现的业务逻辑。围绕在核心周围的是与外界交互的适配器。这些适配器包括数据库访问组件、生产和消费消息的消息传递组件、暴露 API 或实现 UI 的 web 组件。

袁不语
袁不语
翻译于 2015/05/20 15:10
1

尽管具有合乎逻辑的模块化架构,但是该应用做为整体打包部署。具体的样式依赖应用的语言和框架。例如许多Java应用打成WAR包,部署在Tomcat或Jetty这样的应用服务器。还有一些Java应用打成独立可执行的JAR包。类似的,Rails和Node.js应用以目录层次的形式打包。

写成这种形式的应用极其普遍。它们非常易于开发,因为我们的IDE和其他工具专注于构建一个单独的应用。这样的应用通常也易于测试。通过简单地运行应用就可以实现端到端的测试,使用Selenium就可以测试UI。整体应用也易于部署。你仅仅需要复制打包的应用到服务器。你也可以通过在负载均衡器后面运行多个副本的方式扩展应用。在项目的早期阶段,这种方式运作的很好。

袁不语
袁不语
翻译于 2015/05/20 15:32
2

走向整体地狱(Monolithic Hell)

很不幸,这种简单的方式有一个巨大的限制。成功的应用都会随着时间增大,最终变得巨大。在每一个冲刺(sprint),你的开发团队实现了许多用户故事,这当然意味着添加了许多行代码。经过几年之后,原本很小、很简单的应用将会长成可怕的庞然大物。举一个极端的例子,我最近与一个开发者进行了一次谈话,他写了一个工具分析他们数百万行代码的应用中的成千上万个JAR包的依赖。我很确定这样一个怪兽是由大量的开发者经过数年的共同努力才制造出来的。

一旦你的应用变成了一个复杂的庞然大物,你的开发团队就可能生活在痛苦之中。敏捷开发的任何尝试和交付将会举步维艰。该应用的一个主要问题是过度地复杂。它仅仅是太大了以至于任何一个开发者都不能完整地理解。因此正确地修复漏洞和实现新功能将会变得困难和耗时。更糟糕的是,这形成了一个恶性循环。如果基本代码难于理解,就很难做出正确的改动。那么最终就会成为一个可怕的、无法理解的大泥球

袁不语
袁不语
翻译于 2015/05/20 17:04
2

应用程序的规模也会拖慢开发进度。应用程序的规模越大,启动的时间越长。例如在最近的调查中,开发者表示启动时间长达12分钟。我也道听途说过启动时间长达40分钟的应用程序。如果开发者不得不周期性重启应用服务,那么他们一天中很大一部分时间将浪费在等待上,他们的生产力将会受到影响。

巨大的、复杂的整体应用程序的另外一个问题是它是持续部署的障碍。目前,SaaS应用通常在一天之内会多次将改动推到生成环境。对于复杂的庞然大物,这极其难处理,因为你必须重新部署整个应用来更新程序的任何一小部分。我前面提到的冗长的启动时间也将产生不利的影响。而且因为改动的影响通常不能被充分的理解,那么你可能还必须做更广泛的手工测试。最终导致持续部署几乎是不可能的。

袁不语
袁不语
翻译于 2015/05/20 17:51
2

当不同的模块具有资源需求冲突的时候,整体应用程序也将难以扩展。例如,某个实现CPU密集型图像处理逻辑的模块非常适合部署在AWS EC2 Compute Optimized instances。另外某个内存数据库的模块最适合部署在 EC2 Memory-optimized instances。然后由于这些模块都得部署在一起,所以你不得不在硬件的选择上做出妥协。

整体应用程序的另外一个问题是可靠性。因为所有的模块都在同一进程内运行,所以任一模块的漏洞,比如内存泄露,将会影响整个进程。此外,因为应用程序的所有实例是一致的,所以这些漏洞将会影响整个应用的可用性。.

最后但并非不重要,整体应用程序使得采用新框架、新语言极其困难。举个例子来说,假设你有两百万行使用XYZ框架写的代码。那么使用新的ABC框架重写整个应用将会是极其昂贵的(无论是时间还是花费),即使新框架相当的好。因此对于采用新技术,整体应用程序具有巨大的障碍。当你开始新的项目的时候,你将非常纠结于选择哪种技术。

袁不语
袁不语
翻译于 2015/05/20 20:22
2

总而言之:你有一个已经长成可怕的庞然大物的,几乎没有开发者可以理解的,成功的业务关键应用。这个应用程序使用过时的、没有生产力的技术写成,这使得招聘优秀的开发者变得非常困难。这个应用程序难以扩展而且不可靠。因此,敏捷开发和应用交付是不可能的。

所以你能怎么办呢?

微服务 – 处理复杂性

许多组织,比如Amazon、eBay和Netflix,已经采用现在被称为微服务架构模式的方法解决了这个问题。其想法是将应用程序分割成更小的相互关联的服务,而不是构建单个可怕的整体应用程序。

袁不语
袁不语
翻译于 2015/05/20 20:48
1

一个服务通常实现一组独立的特性或功能,比如订单管理、客户管理等。每个微服务是一个具有六角形架构的迷你应用,其自己的六角形架构包含业务逻辑以及许多适配器。某些微服务将会暴露供其他微服务或者客户端使用的API。另外一些微服务可能实现web UI。在运行时,每个实例通常是一个云虚拟机或者一个Docker容器。

例如,前文所述的系统的一个可能的分解如下图所示:

Graph-03

应用的每个功能区域现在以微服务的方式实现。此外web应用程序分割成了一组更简单的web应用程序(一个面向乘客的,一个面向司机的)。这使得更容易为特定的用户、设备或特定的用例部署单独的服务。

袁不语
袁不语
翻译于 2015/05/20 21:14
1

每个后端服务暴露一套 REST API,大部分服务调用其他服务提供的 API。例如司机管理模块使用通知服务告知空闲的司机可能的订单。UI 服务调用其他服务来渲染 web 页面。服务也可能使用异步的、基于消息的通信方式。服务间通信将会在本系列后面的文章中详细讨论。

某些 REST API 是暴露给司机和乘客使用的移动 app 的。然后 app 不能直接访问后端服务,其间的通信是通过称为 API 网关的媒介传递的。API 网关负责负载均衡、缓存、访问控制、API 测量和监控,该模块可以使用 NGINX 有效的实现。本系列后面的文章将会讨论 API 网关。

Graph-05

袁不语
袁不语
翻译于 2015/05/21 15:23
2

微服务架构模式对应扩展立方体(Scale Cube)的 Y 轴扩展,扩展立方体是《The Art of Scalability》一书中描述可扩展性的 3D 模型。此外还有两个扩展维度,X 轴扩展表示在负载均衡器后面运行多个相同的应用程序副本,Z 轴扩展(数据分割)表示使用请求中的某个属性(例如数据表主键或用户 id)来路由请求到特定服务器。

应用通常综合使用三种扩展。Y 轴扩展分解应用程序到微服务,就像上图展示的那样。在运行时,为了吞吐量和可用性,X 轴扩展在负载均衡器后面运行多个服务的实例。某些应用也可能使用 Z 轴扩展分割服务。下图展示了如何使用 Docker 将订单管理服务部署在 AWS EC2 上。


Graph-02

袁不语
袁不语
翻译于 2015/05/21 15:56
2
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(32)

qwfys
qwfys
+1
飞天0407
飞天0407
翻译的真不错,看完基本就可以了解了微服务是干嘛的了已经为什么需要微服务
regulusun
regulusun

引用来自“BaiYang”的评论

这不就是 SOA 么?又起了个叫微服务的小名?

引用来自“0Scn”的评论

94! 只不过比起有些所谓的SOA架构来说粒度更小些罢了。何况SOA本身就没有真正意义的公认的权威的标准定义,某所谓的SOA标准组织给的定义也是极为抽象的。说白了就是为迎合现实的快速发展而带来的更高的互联互通以及灵活性的需求,通过遵循标准化封装、松耦合可编排、复用这三个要点来设计实现。至于落地如何具体设计实现,那本就是依实际应用场景不同而见仁见智的东西。IT行业确实是术语和缩写流行泛滥的行业之一,为了不落人后,某个时段大家总是要争先恐后地跟进的。好吧,为业内方便沟通,为科技进步引领趋势……不管术语和缩写怎么滴好,但总不可避免鱼目混珠,泥沙俱下而导致很多人被混绕视听的。你看,我们老祖宗搞的“统一文字+活字印刷”就很SOA很微服务嘛,N年前我们都如此高大尚了,有木有!
完全同意,微服务即SOA-
andot
andot

引用来自“innerp”的评论

其实 我很好奇 服务直接为什么一定要用rest api ,用rpc性能是不是更好勒
你说的对,RPC 可以提供更好的微服务。Hprose 就是一个很好的微服务 RPC,支持众多语言(支持常用的20多种语言),而且支持众多底层协议(如 HTTP、TCP、WebSocket 等)。没有传统 RPC 的缺点,而且比 REST API 更加轻量级,更加快速,更加易用。
金贞花
金贞花
我正在路上
单车架构师
单车架构师
在我看来只是换个概念而已,还是逃分布式系统的圈子!
0Scn
0Scn

引用来自“BaiYang”的评论

这不就是 SOA 么?又起了个叫微服务的小名?
94! 只不过比起有些所谓的SOA架构来说粒度更小些罢了。何况SOA本身就没有真正意义的公认的权威的标准定义,某所谓的SOA标准组织给的定义也是极为抽象的。说白了就是为迎合现实的快速发展而带来的更高的互联互通以及灵活性的需求,通过遵循标准化封装、松耦合可编排、复用这三个要点来设计实现。至于落地如何具体设计实现,那本就是依实际应用场景不同而见仁见智的东西。IT行业确实是术语和缩写流行泛滥的行业之一,为了不落人后,某个时段大家总是要争先恐后地跟进的。好吧,为业内方便沟通,为科技进步引领趋势……不管术语和缩写怎么滴好,但总不可避免鱼目混珠,泥沙俱下而导致很多人被混绕视听的。你看,我们老祖宗搞的“统一文字+活字印刷”就很SOA很微服务嘛,N年前我们都如此高大尚了,有木有!
BaiYang
BaiYang
这不就是 SOA 么?又起了个叫微服务的小名?
大胖森
大胖森
微服务实战(一):微服务架构的优势与不足 【编者的话】本文来自Nginx官方博客,是微服务系列文章的第一篇,主要探讨了传统的单体式应用的不足,以及微服务架构的优势与挑战。正如作者所说,微服务架构更适合用于构建复杂的应用,尽管它也有自己的不足。
小鸽子咕噜
小鸽子咕噜
还不错 部分翻译生硬
返回顶部
顶部