对微服务的简单思考

今天阅读了文章《微服务架构在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 条评论
登录 后参与评论

相关文章

来自专栏CSDN技术头条

PingCAP刘奇:如何构建一个NewSQL数据库

大家好,我是PingCAP CEO刘奇。今天我将和大家分享一下如何构建一个NewSQL数据库。 首先,来介绍下我自己。和你们当中很多人一样,我是一名开源Hack...

21810
来自专栏后端技术探索

从既有系统到微服务架构

微服务近年来可谓炙手可热,合理的使用微服务架构可以解耦系统、提供更好的软件伸缩性以及提高组织的敏捷性。然而现实中较少有项目一开始就会选择使用微服务架构,绝大多数...

592
来自专栏猿天地

月入三万的程序员,都掌握了这七大知识点

——常见的设计模式,编码必备,Spring5,做应用必不可少的最新框架,MyBatis,玩数据库必不可少的组件......

722
来自专栏企鹅号快讯

分库分表架构实践

作者介绍: 丁浪,现就职于某垂直电商平台,担任技术架构师。关注高并发、高可用的架构设计,对系统服务化、分库分表、性能调优等方面有深入研究和丰富实践经验。热衷于技...

27910
来自专栏技术专栏

Springcloud(二)-拆分微服务(慕课网廖师兄SpringCloud微服务实战)

Organizations which design Systems are constrained to produce design which are c...

1922
来自专栏编程

前端工程化衡量准则

小编说:前端工程化这个概念在近两年被广泛地提及和讨论,究其原因,是前端工程师所负责的客户端功能逻辑在不断复杂化。本文介绍了前端工程化的衡量准则以及3个阶段。 如...

2345
来自专栏程序人生 阅读快乐

[Hadoop权威指南](第二版)中文

本书是您纵情享用数据之美的得力助手。作为处理海量数据集的理想工具,Apache Hadoop架构是MapReduce算法的一种开源应用,是Google(谷歌)开...

461
来自专栏数据科学与人工智能

数据质量监控的那些事

0x00 前言 往往那些不起眼的功能,最能毁掉你的工作成果。 本篇分享一些和数据质量监控相关的内容。数据质量监控是一个在快速发展的业务中最容易被牺牲和忽略的功能...

4825
来自专栏芋道源码1024

浅谈高性能数据库集群 —— 分库分表

最近学习了阿里资深技术专家李运华的架构设计关于分库分表的教程,颇有收获,总结一下。

751
来自专栏Java技术

一篇故事告诉你什么是微服务架构!

看到最近“微服务架构”这个概念这么火,作为一个积极上进的程序猿,成小胖忍不住想要学习学习。而架构师老王(不是隔壁老王)最近刚好在做公司基础服务的微服务化研究和落...

763

扫码关注云+社区