• 作为微服务的设计者 你需要像一个设计师一样去设计规划
  • Cvlrt 发表于 2016/3/14 21:36:00 | 分类标签: 架构设计 设计师 微服务
  • 在对微服务和微服务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)。
  • 请您注意

    ·自觉遵守:爱国、守法、自律、真实、文明的原则

    ·尊重网上道德,遵守《全国人大常委会关于维护互联网安全的决定》及中华人民共和国其他各项有关法律法规

    ·严禁发表危害国家安全,破坏民族团结、国家宗教政策和社会稳定,含侮辱、诽谤、教唆、淫秽等内容的作品

    ·承担一切因您的行为而直接或间接导致的民事或刑事法律责任

    ·您在编程中国社区新闻评论发表的作品,本网站有权在网站内保留、转载、引用或者删除

    ·参与本评论即表明您已经阅读并接受上述条款

  • 感谢本文作者
  • 作者头像
  • 昵称:Cvlrt
  • 加入时间:2013/5/22 0:00:00
  • TA的签名
  • 这家伙很懒,虾米都没写
  • +进入TA的空间
  • 以下内容也很赞哦
分享按钮