微服务之旅的经验分享

多年来,我们一直努力展示众多微服务实践者在采用微服务的过程中获得的经验和教训。 Piotr Gankiewicz
是一名软件工程师。他踏上了 微服务之旅
,现在决定分享一些过程傍边的 经验和教训
。当然,就像所有的经验一样,它不是全都与你的实践相关,可是这些经验和教训还是值得了解的。正如Piotr说的:

不久前,我终于决定深入到 微服务
的世界了。我确实花了相当长的时间寻找使用这种架构模式的机会,并最终找到了。在经过三个月的考试和学习,其中大部门都是自学(困难的方式),我相信是时候分享一些经验了。

他从讲述一些核心的系统设计方面开始,其中包孕API管理(gateway)。他引入了“服务总线”的概念,而没有真的定义它。他还讨论了存储服务的添加:

[…] 为了在只读数据库(这里就是CQRS一类的东西)中存储对象,你很可能需要订阅所有类型的事件,像UserCreated和InvoicePaid等等。然后你需要与特定的(微)服务通信获取数据,然后将它存入数据库中。在这种场景下,你的API需要负责订阅事件、映射数据和积存数据到数据库。这有问题吗? 多数情况下当然没有。可是,我更倾向于下述解决方案。它将API和微服务完全分离。这样,就泛起了所谓的存储服务,由它来订阅事件,从(微)服务获取数据等等。存储服务知道怎样扁平化数据。API只需要给存储服务发送HTTP请求来获取数据。它并不需要关心数据是从哪里来的,是内部的数据库,还是缓存,还是处于天涯海角的某个服务。

最后在给出他的经验和教训(他称为“小贴士和窍门”)之前, 他用对服务的定义总结了设计方面。服务的部门定义包孕:

每个(微)服务处理自己的领域模型、仓库、业务逻辑等等。整个基础服务唯一共有的是服务总线和一套命令和事件集合。

那么回到小贴士和窍门。我们这里只包含其中一部门。对那些认为微服务的巨细重要的人,首先是“让服务尽量小”。

建立多个小型的专注于单一领域的微服务比建立少量臃肿的执行完全分歧任务、在相同的范围内管理不相干职责的微服务要好。最常见的例子有:建立/验证用户账户、 发送消息、管理产物、处理支付等等。每个领域纳入到零丁的有独特实体的服务中。

从别人对 微服务、事件溯源和CQRS
的说法展开,Piotr认为CQRS至关重要:

遵循CQRS,你需要做的全部事情是发送无返回值的命令和执行幂等的查询。如果你遵循这一模式,你会很快发现扩展应用法式简单多了,只需要分离读写操作。

接下来回到数据。为服务选择数据库的方式至关重要。这再次和其他人讨论的相似:

每个服务(不是单个服务实例,因为你可能有许多同一服务的实例运行在分歧的节点上)都应该有自己的数据库。这样你不仅能消除单点故障(整个系统使用单一的庞大数据库) ,最重要的是还能自由选择最适合特定任务的数据库。你可能想使用SQL执行严重依赖事务的金融操作,或者使用NoSQL数据库存储数十亿JSON文档。

Piotr提到了其它一些事情,如请求追踪(他举例说明了在他的学习之旅中的实现方法 )、使用异步消息方法(使用HTTP)、确保新服务易于摆设(可能隐晦地引用到持续集成和持续摆设)以及编写端到端测试。最后提到的是“包含故障恢复、服务发现和其它一些有用的机制"。

任何时候犯错了,你可能希望包管整个系统不会溃散或者至少其中一部门不会溃散。确保你引入了重试机制(好比 Polly
)、服务发现工具,如 Consul
以及集中积存证书,好比使用 Vault
Azure Key Vault
或者我的开源项目 Lockbox

Piotr讨论的大部门和过去这些年别人说的非常相似,所以在使用微服务开发时我们很可能正趋向一个关于方法有效还是无效的共识。可是需要注意的是,尽管Piotr讨论了他的一些经验和教训,可是没有任何关于他开发的应用法式阐发如何的说明(负载下扩展、恢复能力等等)。可能后期会有,我们拭目以待。

查看英文原文: Sharing Experiences from a Microservices Journey

感谢冬雨对本文的审校。

给InfoQ中文站投稿或者介入内容翻译工作,请邮件至editors@cn.infoq.com。也欢迎各人通过新浪微博(@InfoQ,@丁晓昀),微信(微信号: InfoQChina
)关注我们。

评论

还没有任何评论,你来说两句吧

发表评论