微服务(二)

作者:James Lewis/Martin Folwer
翻译:Zhang Yang

围绕业务功能组织

仔细看大型应用程序分成的几个部分,往往管理的重点在技术层面上,产生用户界面团队,服务器端功能团队和数据库团队。当这些团队沿着这些线路分开,即使是简单的改变也可以导致一个跨团队项目,需要花费时间和预算。一个聪明的团队将优化解决这个,两害取其轻-强迫分配业务到它涉及到应用程序中。业务逻辑无处不在。这里有一个Conway’s Law in action[5]的例子。

任何组织,它设计一个系统(广义上的),会产生这样的设计:其结构将复制组织的通信结构。
- 梅尔文·康威,1967年

这里写图片描述
图2:Conway’s Low in action

微服务的分工方法是不同的,围绕业务功能分解成多个服务。这些服务为业务领域采取软件的宽栈实现,包括用户界面,持续性存储和外部协作。因此,团队是跨职能的,包括全方位的所需开发技能:用户体验,数据库和项目管理。

这里写图片描述

图3:团队边界加强服务边界

www.comparethemarket.com以这种方式进行了组织。跨职能团队负责建设和经营的每个产品,每个产品拆分为多个独立的服务通过消息总线进行通信。

大型整体件应用程序也可以始终围绕业务功能模块化,虽然这不是常见的情况。当然,我们可以要求一个庞大的队伍,来建设整体件应用,依据业务线划分自身职能。我们在这里看到的主要问题是,他们往往是围绕了太多的上下文。如果整体件跨越许多模块化的边界,可能很难要求团队的成员用他们的短期记忆,处理他们面对的状况。此外,我们看到,模块化线路需要大量的纪律约束。服务组件必需的间隔越明确,团队边界越容易清晰。

产品没不是项目

我们看到的绝大多数软件开发使用项目模型:其目的是发布一些的软件片段,然后视其为完成。完成了的软件会交给维护团队,项目团队解散。

微服务的支持者倾向于避免这种模式,而愿意应该在产品的整个生命周期中,让一个团队拥有一个它。一个常见的启示是亚马逊的口号,“ you build,you run it”,那里一个开发团队需要对生产的软件的负全部的责任。这使开发者不得每天都关心产品中他们的软件行为,并增加与用户的接触,因为他们必须承担至少部分的支持工作。

产品的心态,关系到商业能力。与其将软件视为一套完成的功能组合,不如将其视为一段与用户的持续的联系,期间关注软件如何协助用户增强商业能力。

不知道为什么整体件应用程序不能采取同样的方法,但更小粒度的服务可以更容易地建立,开发人员和用户之间的人际关系。

智能终端和沉默管道

在构建不同进程之间的通信结构时,我们已经看到很多的产品和方法,它们强调将智能放入通信机制本身。这方面的一个很好的例子就是企业服务总线(ESB),它往往提供复杂的工具,用来消息路由,编排,转换和商业规则。

微服务社区赞成另一种方法:智能终端和沉默管道。依据微服务构建应用程序的目标是尽可能的去耦和,内聚性地–他们拥有自己的业务逻辑,像经典的Unix意义上的过滤器一样行为–接收请求,恰当的应用业务逻辑,并产生一个响应。这里使用简单的RESTish协议,而不是复杂协议如,WS-编舞或BPEL或业务流程编排,或者中央控制式。

最常用的两个协议是带资源API的HTTP请求-响应和轻量级通信[6]。前一个最好的表述是:

就是Web,而不是在Web后面
- 伊恩·罗宾逊

微服务团队使用的原则,也是万维网(并在很大程度上Unix也是)的基础。通常使用的资源可以被缓存,而开发/运营人员只需要花费很少的时间。

第二种方法常见于通过轻量级消息总线通信,它的基础选择通常是沉默式的(沉默得只充当消息路由器) -如RabbitMQ或ZeroMQ一样的简单实现,仅仅提供了可靠的异步媒介 – 在服务中,智能的终端产生和消费信息。

在整体件中,组件们在进程中执行,通过方法调用或者函数引用进行通信。将整体件改成微服务的最大的问题在于改变通信模式。单纯的从内存方法调用转换到RPC会导致表现很差的繁琐通信。相反,你需要用一个粗糙粒度通信方法代替精细的方法。

备注:
5: The original paper can be found on Melvyn Conway’s website here
6: At extremes of scale, organisations often move to binary protocols - protobufs for example. Systems using these still exhibit the characteristic of smart endpoints, dumb pipes - and trade off transparency for scale. Most web properties and certainly the vast majority of enterprises don’t need to make this tradeoff - transparency can be a big win.

转载于:https://my.oschina.net/windmissing/blog/690455

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值