本文由DevOps时代高翻院翻译整理译者:素人派

本文将介绍微服务设计画板,以及微服务架构是如何在“美国第一资本投资集团”中应用的。

随着更多的组织在实践微服务,微服务架构变得更加成熟。然而,早期的微服务活动关注在如何把单个Web程序解偶成多个服务,更大更多的组织为了提高他们的软件交付速度和可伸缩性,也正在把已有的软件生态迁移成服务。这个问题显然要比拆分大的系统要更复杂,更具有挑战性。

模块化主要是为了解决分布式系统的复杂性。这既是微服务架构流行起来的原因,也是指导如何着手的一个重要提示。找到服务之间正确的边界自然是很重要的,组织采用微服务减少团队直接的协调。

这项与技术无关的设计工作处理必要的软件复杂性问题,用于不断地改进软件的演进和持续。即使边界划分好以后,设计工作还是不可或缺的。

微服务设计面板


微服务活动被研发人员驱动着,几乎接近敏捷方法、DevOps的潮流。更快的软件交付需求也带动着微服务。随之而来的,研发人员会快速地编码,基于紧急的设计来指导他们的工作,这就导致会出现低效的服务。

另外过度的服务设计也会降低开发效率,破坏微服务架构的优势。如何进行适当的设计是需要考虑的。

根据西蒙·布朗的“尽量前置设计”理念,微服务设计画板是为了抓住重要服务的特性,以指导服务的开发以及消费。

图 1 - 微服务设计画板。

除了服务的名称和描述外,画板上还包括下面的内容:

理论上,一个服务的设计者应该能完成上面表格列出的内容,并依据画板抓住服务的重点。这里给出一个交易搜索服务的例子:

图 2 - “交易搜索”的微服务设计画板

第一资本投资集团的微服务


第一资本在早期已经引入了微服务架构,并在全公司的线上产品中有几百个在运行着。他的技术体系是复杂而且庞大的,并不是所有的都以微服务的形式构建的。

微服务正在蓬勃地发展中,很多不同的团队在日常工作中根据自己的实际情况在尝试。在2017年,第一资本的管理团队申明他们的微服务运用能力已经成熟,并将为开发团队提供微服务采用策略、实现指导以及培训。

为了能够让微服务在整个组织内推广,第一资本首先需要确定一个共同的目标。当在分析微服务效果时,第一资本的团队认为新架构的能力是允许研发人员可以快速迭代而不用在质量和安全问题上作出妥协。这个领导团队中的Irakli Nadareishvili解释到:

长期以来,软件工程师认为必须在速度和安全的问题上作出妥协:快速构建或者高质量的构建。这样的妥协给人一种很直观的感觉。复杂的系统是由很多团队开发出来的,他们分布在一个应用的不同部分上。这些团队之间时不时地需要进行协调,这时候你有两个选择:

  • 忽视协作的需要而保持高效,这样会导致有一些破坏;

  • 或者你认为需要协作而降低效率。

但是,如果我们有一套系统可以最小化这些协作的需求呢?那么,就不需要经常在效率和安全之间做选择了。如果团队能够独立工作,并且是基于小批量的,就可以采用这样的设计。对我们来说,这就是微服务架构的要点。

第一资本的微服务设计


很多组织在寻找微服务的大小把握上遇到了问题。根据第一资本的微服务设计分析,优化微服务的大小是在随着时间在继续,例如微服务的先驱Netflix:

在第一资本,他们不期待找到服务边界。反而这些边界会随着时间的推移而有变化,高效的团队会高效、安全地进行研发。

在研究如何设计微服务时,第一资本的团队采用领域驱动设计(DDD)作为突破点。他们发现边界上下文的概念对于复杂的系统是极其有用的。然而,他们认为,在组织中应用DDD的深度需要专业知识和经验,大多数软件团队是不具备的,尝试的话可能会有代价并难以持续。

第一资本在AlbertoBrandolini的事件风暴方法论中找到了DDD可行的捷径。这种在软件行业中迅速流行的新方法允许团队探索一个复杂的领域——包括识别边际上下文——在短短4个会话中。

除了工作以外的产品,第一资本发现事件风暴是一个协作包容的活动,他有助于快速地开发可以在工程师、产品、设计以及其他的相关团队之间互相认同的产品。

第一资本的微服务设计画板


第一资本发现事件风暴虽然非常有用,但还是有个问题,就是无法数字化和文档化。因此,他们不仅仅想要的是列出上下文边界和热点,于是决定把微服务设计的结果使用微服务设计画板保存下来。Higginbotham团队成员James重新排列了画布,更像下面的商业式画布:

图 3 - “支付管理服务”的微服务设计画板(仅供演示)

到目前为止,第一资本的团队发现画板是一个描述微服务设计的一个好办法。重要地,他们有能力使用画板作为一个非侵入式的方法来帮助他们减少团队之间的协作,这样可以提高交付效率而不用在安全性和稳定性问题上作出妥协。

微服务架构设计的思考


正如第一资本承认的那样,微服务边界会随着时间的推移而改变,微服务设计画板的结构也会随着个人和组织的应用而变化。

它的价值应该依据它是如何有效地满足目标来衡量:为了帮助处理复杂的分布式软件系统,提供一个简单的工具,用来在合适的时间捕捉足够的设计思想。

原文链接:https://dzone.com/articles/streamlined-microservice-design-in-practice
©著作权归作者所有:来自51CTO博客作者mob604756e605af的原创作品,如需转载,请注明出处,否则将追究法律责任

更多相关文章

  1. 作为业界的经典框架,设计模式如何在Spring中的应用?
  2. MongoDB系列12:MongoDB电子商务产品目录模型设计
  3. [翻译]微服务设计模式 - 3. 按业务功能拆分模式
  4. [翻译]微服务设计模式 - 4. 服务发现 - 客户端服务发现
  5. H5互动游戏如何设计制作
  6. 【H5页面设计规范】H5页面从形式上和内容上如何设计走入人心
  7. [翻译]微服务设计模式 - 1. 单体应用模式
  8. [翻译]微服务设计模式 - 2. 微服务应用模式
  9. 公有云上基于微服务架构 SAAS 产品研发实践

随机推荐

  1. android 国内镜像
  2. android-使App全屏 - 随心
  3. Dowload android source code
  4. android中修改tablayout中的字体大小和颜
  5. android底部中间凸出导航 BottomProtrudi
  6. Android P WMS addwindow流程
  7. fill_parent和wrap_content的问题
  8. Android连接SpringMVC配置信息
  9. RadioButton 带下划线切换的案例
  10. Android studio一些设置项