微服务架构设计须避开工程师思维

  • Jan Stenberg
  • 艾利特

2016 年 3 月 13 日

话题:语言 & 开发架构

在对微服务和微服务 API 进行设计的时候,开发者最好能站在用户的角度像一个设计师一样去设计规划,Nic Benders 在最近举行的Microservices Practitioner Summit峰会上如是说。正如红帽所说 API 应该是微服务的重点,然后通过“由外向内”的方法来构建微服务。

这里来介绍一下 Benders,他是 App 性能管理服务商New Relic公司的首席架构师,New Relic 也是一家从开发单体架构应用开始的公司,随着用户基数的不断增长,应用的功能设定也有所升级改版,更重要的是,服务的能力也在不断的提升。而正是因为这些方方面面的数据都在增长,导致更多的问题频繁出现。也正是基于这样一个大的背景下,New Relic 公司在经过几年的分析思考之后,决定从原来的单体架构模型迁移到微服务架构

正是在这个迁移到新架构的过程中,Benders 发现他们所犯下的最大错误就是被固有的“工程师思维模式”所局限了双眼。以数据层开始着手从内向外构建服务,然后通过业务逻辑将数据层往外迁移,这也就意味着 API 的设计工作接近尾声了。如果说真的是按照这个流程来执行的话,只能说制作这样一个 API 从业务逻辑上来说是有意义的,但是并不能满足庞大的用户需求。当然,在设计过程中也会有很多来自团队的不同声音和决策,部分决策当然会限制 API 的性能,同时也不能完全将用户的需求考虑进去。对此,Benders 坚持认为,API 的设计对产品起到了决定性作用,开发人员一定要像设计师那样去思考,而不仅仅是工程师。

When designing a system, you need to think like a designer。

对于系统的整体设计,要具备设计师那样的艺术思维。

使用这样的方法开始设计一个新的产品,同时兼顾要解决用户提出的问题,这样一款新产品如何解决用户问题,产品测试阶段还得和真实用户结合到一起才能最终得出解决方案。用户使用什么样的服务只是一个需求,跟开发者在开发这款服务时使用的什么样的模型根本就没多大关系,更重要的是在对 API 进行设计的时候使用了“由外向内”的设计方法,根据 API 的定义规则,实现对 API 的服务的支持则由开发者来决定的。Benders 将之与测试驱动开发(Test-Driven Development,TDD)相比较,TDD 是在实现驱动之初就已经将测试程序写好了。

通常情况下,Benders 在设计 API 的时候,前期都会以写一些伪代码仿真程序来对抗 API 来开始,如果 API 运行不顺畅不兼容,届时再改变现有的参数和方法也来得及。另一个在他看来很有效的方法就是先写文档,简化和那些真正会使用这一 API 的用户之间的交流。

Benders 还指出,对系统的设计可以改变人们使用它的方式,而如果一个系统能够简化创建服务的流程的话,将有可能鼓励用户自行来创建更多的服务,系统能够更方便的集中报告日志,同时还能集中管理。设计决策并不是为了解决现有的问题,它同样也是一个引导长期使用服务的方法——更简单的完成任务,而其他人却很难完成。通过改变设计,开发者就可以鼓励用户按照一种特定的行为模式来使用新的服务。

最近 Anders Jensen-Waud 在写关于 Thinking Outside-In 方面的内容,有兴趣的可以看看:API 如何实现面向服务架构的最初承诺(How APIs Fulfil the Original Promise of Service-Oriented Architecture)。

查看英文原文:Don’t Think like an Engineer When Designing Microservices

语言 & 开发架构