对微服务的简单思考

今天阅读了文章《微服务架构在Netflix的应用:架构设计的经验教训》,引发了我对微服务的一些感想。大约这些感想平日都在大脑里装着没有声响,这篇文章算是酵母,投进去,发了酵,开始有些微醉薄醺的味道了。

这篇文章介绍了Cockcroft的微服务架构经验。Cockcroft是Battery Ventures公司的技术人员,是微服务和云架构方面著名的布道者,目前供职于Nginx技术咨询委员会。

一直以来,微服务虽然风生水起,不过却没有什么靠得住的定义可以得到多少人公认的。Cockcroft对微服务的定义却引起了我的注意。定义如下:

由松耦合的有相应语境的元素构成的一种面向服务的架构,松耦合意味着你可以独立更新这些服务。更新其中一个服务并不会改变其他的服务。

最后一句话可以看做是验证服务设计是否合理的一个标准。这里提到的“更新”,不仅意味着服务实现的变化,关键是它意味着“部署好的服务”的更新,如此才能体现服务的物理边界,而这正是微服务所要解决的单块架构的弊病。

在向微服务迁移的时候人们常常会把数据库的耦合看的过重,也就是所有服务都连的是同一个数据库,更新其中一个服务就意味着要改变数据库的schema。这种情况你需要对数据库进行拆分。

我只能表示部分同意这个观点,因为我们需要考虑数据库拆分的成本,因为它可能会带来维护成本的增加,此外还有拆分数据库会产生的影响,例如需要考虑数据的同步、分布式事务等系列问题。

在文章末尾,作者旗帜鲜明地强调了这一观点,并将其列入微服务架构设计最佳实践的第一原则:“每个微服务的数据单独存储”。但我觉得这个约束可能会导致微服务的粒度过粗,且可能导致微服务的设计者过度地考虑数据库Schema,而忘记从领域的角度去划分服务边界。正如Jan Stenberg的文章《微服务架构设计须避开工程师思维》就认为“开发者最好能站在用户的角度像一个设计师一样去设计规划”,他认为:

以数据层开始着手从内向外构建服务,然后通过业务逻辑将数据层往外迁移,这也就意味着API的设计工作接近尾声了。如果说真的是按照这个流程来执行的话,只能说制作这样一个API从业务逻辑上来说是有意义的,但是并不能满足庞大的用户需求。

服务的分离并不绝对代表数据应该分离,从具有悠久历史的ORM框架的存在就已经证明数据Schema与领域逻辑必然是“阻抗不匹配”的,强调这个约束,可能会导致设计陷入“数据驱动设计”的危险境地。

个人认为,降低数据约束的设计原则是尽可能避免多个服务对同一个数据存储进行写操作。而读操作则不在限制之列。在我们开发的产品中,CData微服务会在HDFS上创建Parquet格式的数据集,而另一个微服务则会对这个数据集的数据进行读取。虽然这两个服务共享了存储的数据,但读写却是分离(或者说命令查询分离)的,无论从性能、可扩展性还是其他质量属性去考虑,这样的设计都是无可厚非的。没有数据存储的约束,我们就可以从业务角度去划分微服务。

文中提到了Bounded Context,这是我非常认可的,甚至觉得DDD与Micro Service的理念是天然融合的,BC就是驱动出Domain Service的最佳起点。

在微服务这个概念兴起之前,我们有项目就已经通过BC驱动出各个粒度较小且松散耦合的Domain Service,并基于RESTful的架构风格设计服务API。所以微服务并不是什么时髦新潮的玩意儿,数十年前的DDD已经这么要求了,只是没有一个概念来清晰定位罢了。

如果我们再结合Robert Martin提出的Clean Architecture的概念,那么,一个微服务就与Application相对应,而Application则可以映射为一个Feature级别的Use Case,恰好对应了DDD分层架构中应用服务层中的应用服务。还可以引入Cockburn的六边形架构,它可以帮助我们分清楚服务的物理边界和逻辑边界。

许多人在理解物理边界时,会错误地以为只要模块分为独立的Jar包(或者.NET平台下的DLL)即可以认为是物理分隔,实则真正的物理分解是要从运行视图的角度去判断。在同一个JVM中运行的Jar包,都应该视为是逻辑分离,而非真正意义上的物理分离。微服务定义中的服务必须是物理分离的服务,如此才能满足真正意义的服务独立进化。

Netflix团队提出了几条设计和实现微服务架构的最佳实践:

  • 每个微服务的数据单独存储
  • 使用类似程度的成熟度来维护代码
  • 每个微服务都单独进行编译构建
  • 部署到容器之中
  • 将服务器看做是无状态的

除了针对第一条原则我心存疑虑外,后面诸条原则我均表示一百二十分的赞成。

原文发布于微信公众号 - 逸言(YiYan_OneWord)

原文发表时间:2016-03-15

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏无原型不设计

更巧妙的表单设计与登陆访问

以下内容由Mockplus团队翻译整理,仅供学习交流,Mockplus是更快更简单的原型设计工具 你觉得一个普通人每天会使用多少次登陆功能呢?数据显示至少1...

2984
来自专栏WebHub

老王:我想成为公司的主力架构师

要想成为软件开发的专家,需要我们完整了解软件开发的流程,并在关键部分掌握丰富经验。

400
来自专栏跨界架构师

分布式系统关注点——初识「高可用」

        咳咳,从这篇开始,正式拉开分布式系统关注点中,我认为第二重要的内容 —— 「高可用」。

802

云监控与服务器监控不同的6个原因

传统的IT监控,一直是针对以服务器为主的基础设施来进行的。然而如果是将应用部署在云端,那么监控会变得很不一样,因为别说监控,我们很有可能都接触不到服务器。对于应...

2347
来自专栏腾讯技术工程官方号的专栏

腾讯研发专家:TXSQL如何成为云计算时代数据库核弹头?

2381
来自专栏小白课代表

草图大师(SketchUp Pro)2016安装教程

1774
来自专栏知晓程序

不要再问我,什么是小程序了……

1332
来自专栏大数据和云计算技术

大数据和云计算技术周报(第59期)

“大数据” 三个字其实是个marketing语言,从技术角度看,包含范围很广,计算、存储、网络都涉及,知识点广、学习难度高。

1082
来自专栏屈定‘s Blog

如何学习一门新技术

最简单的是找一个上手视频,因为视频是非常直观的展示了技术的使用.先学会用是最根本的,对于没有视频的技术的话,就可以搜索XX上手教程,XX学习记录之类的关键词,很...

1763
来自专栏知晓程序

深度解读!小程序新增能力意味着什么?

1453

扫码关注云+社区