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

在对微服务和微服务 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