专栏首页斑斓对微服务的简单思考

对微服务的简单思考

今天阅读了文章《微服务架构在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),作者:张逸

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

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

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

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 微服务一点都不“微”

    通过这几年在项目中实践微服务,为客户提供微服务咨询,我越来越发现所谓“微服务(Micro Service)”其实一点都不“微”!这非Martin Fowler定...

    张逸
  • 系统架构 | 基于微服务架构,改造企业核心系统之实践

    背景与挑战 随着公司国际化战略的推行以及本土业务的高速发展,后台支撑系统已经不堪重负。 在吞吐量、稳定性以及可扩展性上都无法满足日益增长的业务需求。对于每10万...

    张逸
  • 从单体架构到微服务架构

    我在Martin Fowler网站上读到一篇名为How to break a Monolith into Microservices的微服务文章,作者为Thou...

    张逸
  • 2018微服务年之服务网格Service Mesh

    微服务自2014年3月由Martin Fowler首次提出以来,在Spring Cloud、Dubbo等各类微服务框架的帮助下,以燎原之势席卷了整个IT技术界,...

    哲洛不闹
  • 简单聊聊企业应用架构的演变

    早期, 企业的对外提供的服务比较单一, 客户流量也相对不足。 因此将所有的模块,代码打包在一个项目中,集中部署一台机器上。

    终身幼稚园
  • 『互联网架构』软件架构-分布式架构(14)

    那时候的容器之间都没有进行物理的隔离,都是部署在同一个jvm上的。所以久而久之,它们之间互相的耦合互相的依赖,业务之前有千丝万缕的,添加和修改增加新的业务的时候...

    IT故事会
  • SpringCloud-初识微服务(一)

  • 微服务的误读与误解

    Rainbond开源
  • Chris Richardson微服务翻译:微服务介绍

    作者简介:Chris Richardson,世界著名的软件架构师,经典著作《POJOS IN ACTION》的作者,cloudfoundry.com 的创始人 ...

    butterfly100
  • Java程序员,你必须要看的微服务架构设计思想

    软件架构是一个包含各种组织的系统组织,这些组件包括 Web服务器, 应用服务器, 数据库,存储, 通讯层), 它们彼此或和环境存在关系。系统架构的目标是解决利益...

    李红

扫码关注云+社区

领取腾讯云代金券