微信号:infoqchina

介绍:有内容的技术社区媒体

【深度】微服务:分解应用以实现可部署性和可扩展性

2014-06-20 10:27 InfoQ

本文描述了日渐流行的微服务架构模式。微服务背后大的理念是将大型、复杂且历时长久的应用在架构上设计为内聚的服务,这些服务能够随着时间的流逝而演化。微服务这个术语强烈建议服务应该是很小的。


在本文中,你将会学习到采用微服务架构的驱动力以及如何将其与更为传统的、整体(monolithic)架构进行对比。我们会讨论微服务架构所能带来的收益及其缺点。你能够学习到如何解决使用微服务架构时所遇到的关键技术挑战,包括服务间的通信以及分布式数据管理。


整体架构(有时是有害的)

从最早为Web系统开发应用开始,最为广泛使用的企业应用架构就是将应用所有的服务端组件打包成一个单元。很多的企业级Java应用由一个WAREAR文件所组成。


这种所谓的整体架构会有很多的优点。整体架构开发起来较为容易,因为IDE和其他的开发工具都是面向开发单个应用的。它们测试起来很容易,因为你只需要启动一个应用。整体架构的应用也很容易进行部署,因为你只需要将部署单元——一个文件或目录——复制到运行对应种类服务器的机器上就可以了。


这种方式对于相对小的应用来说,工作起来是很好的。但是,对于复杂应用来讲,整体架构就会变得很笨重了。对于开发者来说,大型的整体架构应用会很难理解和维护。对于频繁部署来说,这也是一个障碍。要部署某个应用组件的变更,你必须要构建和部署整个庞大的应用,这会很复杂、有风险、耗时,并且需要与众多的开发人员协调从而导致很长的测试周期。


整体架构使得很难去试验和采用新技术。


将应用分解为服务

幸运的是,有很多其他的架构风格来支持可扩展性。


决定如何将系统拆分为一组服务在很大程度上来讲是一门艺术,不过有一些策略可以提供帮助。拆分服务的一种方式是按照动词(verb)或者是用例来进行拆分。


另外一种拆分方式就是将系统按照名词或者说是资源进行拆分。这种服务会负责给定类型实体/资源的所有操作。


理想情况下,每个服务应该只有很小的一个责任集合。服务设计时,另外一个可以提供帮助的类比对象就是Unix的系统工具。Unix提供了大量的工具集,如grepcatfind。每个工具只做一件事情,通常会做的特别好,而且可以通过shell脚本与其他工具联合起来执行复杂的任务。遵循Unix系统工具的方式对服务进行建模是很好的,这种方式会创建出单一功能的服务。


微服务架构的收益与缺点

这种架构能够带来很多的收益。首先,每个微服务相对比较小。对于开发人员来说,代码更易于理解。


第二,每个服务可以独立于其他服务进行部署。


第三,每个服务可以独立于其他服务进行扩展。此外,每个服务可以部署到最适合其资源需求的硬件上。


微服务架构使得开发的扩展也变得更为容易。


微服务架构同时也能提升故障的隔离性。


最后但并非最不重要的,微服务架构消除了对某个技术栈的长期依赖。


另外,因为服务比较小,使用更好的语言和技术重写它们变得更为可行。这也意味着,如果对一项新技术的尝试失败的话,你尽可以抛弃这个成果,而不会对整个项目带来风险。这与采用整体架构有很大的区别,在整体架构中,初始的技术选择严重限制你将来采用不同语言和框架的能力。


缺点

当然,没有什么技术是银弹,微服务架构有一些明显的缺点和问题。首先,开发人员必须要处理创建分布式系统所带来的额外的复杂性。


微服务架构同样引入了明显的运维复杂性。


同时,部署跨多个服务的特性时,需要认真地协调不同的开发团队。根据服务间的依赖关系,你要创建服务如何按顺序部署的规划。


使用微服务架构的另外一个挑战就是要决定在应用生命周期的哪个时间点上采用这种架构。当开发应用的第一个版本时,这种架构所能解决的问题你通常还不会遇到。另外,使用复杂的、分布式的架构将会延缓开发。


鉴于这些问题的存在,采用微服务架构不应该是草率做出的决策。


更多精彩内容,请点击阅读原文。

 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 谷歌推送Android 7.0:这些改进最值得你注意! 程序员离职前放木马 复制游戏币非法牟利获刑 你的手游遭遇信任危机了吗?从XcodeGhost漏洞事件看手游安全测试 小李!小李!小李!小李!小李!奥斯卡五连呼! Python超赞语法特性, yield 使用浅析