了解微服务艰难的一面

2016年底,我和团队开始构建一个全新的平台。想要实现开发人员的终极梦想——没有遗留代码,无需担心向后兼容的问题,最好的一点是,可以自由选择最适合工作的正确技术。三年后,在很多痛苦和折磨之后,我现在可以做一些反省了。在深入探讨之前,我想宣布两件事。

  • 马后炮意义不大
  • 没有万能的方案

我们无法知道如果选择不同的方式结果是否会不同,但是在之前没有重视的领域/架构方面的确有一些非常重要的建议。现在,我们自认为理解得更透彻了。因此对于那些想要做类似项目的人来说,提出一些我很后悔自己当初没有遵守的建议。

忽略的建议#1:康威定律康威定律认为系统架构会不可避免地以某种方式重构所在企业的组织架构。

随着平台的演进,我们编写并运维着30~40个微服务。其中一些用不同的语言重写过。自从开始构建起,熟练的后台开发人员从来没有超过一名。因为我们一直是小而紧凑的团队,每个开发人员都得在所有服务上工作。团队一起制定架构决策,on call意味着处理任何领域的可能问题。从过高的服务/开发人员比例上你可能会猜到,我们的服务最终是看上去“分离“实际上紧耦合的。这对我们伤害很大。因为耦合紧,所以一直通过同一时间“仅仅“部署跨服务的变更来降低工作量,这直接违反了独立部署[1]的原则。

忽略的建议#2 你不是Google

微服务的一大好处是可以独立扩展。在最初的设计里,我们已经将在规模加大时可能成为瓶颈的组件分离了出来。事实证明,我们所预计的规模远远超出了现实里可能遇到的任何规模。实际上,我们不仅仅凭猜测确定域边界,而且每个服务都有一定的overhead。我们为运维功能运行一系列的sidecar容器和Kubernetes的DaemonSet(比如监控和日志)。这导致我们在这些支撑的基础架构上花费的资源比实际应用程序还多,而且多很多。我这里并不是说使用单体应用更好,但是如果可以重新选择从更为简单的架构开始,我会:

  • 打散,因为我们现在对领域更为自信,可以找到正确的抽象方式
  • 收集真正性能瓶颈处的数据,证明真的是一个问题
  • 重叠支撑基础架构来节省经费

忽略的建议#3:你仍然不是Google

微服务的另一个好处是可以为工作选择最佳的工具。我们选择了很多语言,运行着使用Python,NodeJS和Golang编写的服务。总的来说这样很不错,但是要编写共享库的时候就是个噩梦了,因为同样的功能得用三种不同的语言都实现一遍。我的确相信应该实验不同的工具,但是最终的所有东西都需要能够支撑生产环境并且长期维护。如果编写内部共享库,让服务都用这个库,这就不再是实验而已了。最终我们只能选择单一语言。而结果也很好。尽可能多地实验,但是一定要构建出可以重复使用的主要技术栈,一致性也很有价值。如果你使用相同的工具运维所有服务的时候(比如,Web服务器使用数据库连接),这就尤其重要。忽略的建议#4:所有东西都是权衡微服务架构也有很多缺点。我在这里不会详细介绍(有人已经写过文章[2]了),不过我觉得理解你将要做什么很重要。如果我们坐下来比对优缺点,很可能会发现只有在有多个后台团队,使用不同的软件解决不同问题时微服务架构才有价值。

教训

我们花费了时间和精力转回了之前的道路。在2019年1月份,我们往回一步检视架构,确定了10个耦合很紧的服务,将它们整合成1个服务。
我们也已经缓慢地构建了Python服务,以及一个Golang服务。有些情况下这意味着使用NodeJS重写。最终需要维护的是一个共享的JavaScript库。

收获

如果我可以回到过去,会给当时的自己这些警告:

  • 为已知的问题做设计,对未来的猜测要谨慎
  • 从少数大型服务开始,并且仔细地设计边界。首要法则是一个微服务 比两个要好,除非你真的能找到拆分它们的强烈理由。当然,总是有很多有效的理由,但是确保在决策之前真正理解这些理由。
  • 当实验以及构建MVP服务时,要非常清楚地知道不会做什么并且要坚持住。不然很容易就会陷入维护错误方案的陷阱里。

相关链接:

  1. https://youtu.be/PFQnNFe27kU?t=1352
  2. https://martinfowler.com/articles/microservice-trade-offs.html

原文链接:https://itnext.io/microservices-c8b5dbdd58b8

Image placeholder
IT头条
未设置
  22人点赞

没有讨论,发表一下自己的看法吧

推荐文章
小牛电动艰难的长征路

网络用语“我偷电瓶养你啊”,从视频火到了表情包,热度延续至今,小年轻们在网络上自嘲自己的财务状况,在线下则对偷电瓶的小贼深恶痛绝。而今,乘坐人工智能技术的快船,两轮电动车行业开始向智能化、高端化方向迈

大神讲解微服务治理的技术演进和架构实践

摘要:随着业务的发展,规模扩大,服务越来越多,需要协调线上运行的各个服务,保障服务的SLA;基于服务调用的性能KPI数据进行容量管理,合理分配各服务的资源占用;对故障业务做服务降级、流量控制、流量迁移

微服务架构之「 服务注册 」

微服务架构是一个庞大复杂的工程,为什么说它庞大复杂呢?因为想要做好微服务,就必须先要建设好微服务所需的一系列基础设施和组件。我在前面的文章《架构设计之「微服务入门」》中已经初步介绍过了这些组件,包括:

一站式入口服务|爱奇艺微服务平台 API 网关实战

写在前面在互联网业务微服务化改造过程中,按照以往的服务治理体系,各服务需要单独实现限流、鉴权、监控、日志等通用功能,构建入口时资源申请、工单批复、多系统配置等一系列流程对精力消耗极大,学习成本较高

微服务架构中如何构建一个数据报告服务?

场景描述在微服务架构中,每个微服务负责自己的数据库,微服务A是不允许直接连接微服务B的数据库进行操作的。现在有2个微服务,一个是订单服务,一个是用户服务。有一个数据报告的需求:生成一份包含用户信息的订

前端微服务在字节跳动的落地之路

不少前端团队都面临着独石应用的工程巨大、理解困难和合作混乱的种种问题,微前端或许是一种比较好的解决方案,它允许我们为应用加入新功能而不影响整体结构。但同时,我们可能会付出一些代价,例如重复依赖、团

🚀 Hyperf 发布 v1.1.8 版本 | 企业级的 PHP 微服务云原生协程框架

更新内容 新增 #965新增RedisLua模块,用于管理Lua脚本; #1023hyperf/metric组件的Prometheus驱动新增CUSTOM_MODE模式; 修复 #1013修复Js

🚀 Hyperf 发布 v1.1.9 版本 | 企业级的 PHP 微服务云原生协程框架

更新内容 本周更新主要为DI组件新增了懒加载功能,配置为懒加载后,注入的对象为一个代理对象,在使用到时,才会实现对象的初始化。以及为DIContainer增加了set和define方法来动态的增加对象

🚀 Hyperf 发布 v1.1.9 版本 | 企业级的 PHP 微服务云原生协程框架

更新内容本周更新主要为DI组件新增了懒加载功能,配置为懒加载后,注入的对象为一个代理对象,在使用到时,才会实现对象的初始化。以及为DIContainer增加了set和define方法来动态的增加对象管

《PHP 微服务练兵》系列教程

本系列教程将从零开始使用PHP搭建微服务,涉及知识docker、mysql、Elasticsearch+Kibana日志分析系统、minio文件储存、阿里ACM配置中心、jenkens自动化测试部署、

微服务架构:拆分单体应用的难点

拆分单体应用为服务的难点从表面上看,通过定义与业务能力或子域相对应的服务来创建微服务架构的策略看起来很简单。但是,你可能会遇到几个障碍:网络延迟。同步进程间通信导致可用性降低。 在服务之间维持数据一致

微服务架构的四大金刚利器

Photo@ChristopherCampbell 文 | 孔凡勇概述互联网应用发展到今天,从单体应用架构到SOA以及今天的微服务,随着微服务化的不断升级进化,服务和服务之间的稳定性变得越来越重要,分

从五个方面入手,保障微服务应用安全

随着计算机、互联网技术的飞速发展,信息安全已然是一个全民关心的问题,也是各大企业非常重视的问题。企业一般会从多个层次着手保障信息安全,如:物理安全、网络安全、系统安全(主机和操作系统)、应用安全等。对

基于JWT规范实现的认证微服务

本文由公众号EAWorld翻译发表,转载需注明出处。作者:MarceloFonseca译者:白小白 原题:Buildinganauthenticationmicro-servicewithJWTsta

一个知名网站的微服务架构最佳实现

译者:蓝梦,十余年研发经验,现就职于某上市互联网公司。作者:小马,Medium 首席架构师。译者有话说,如果你的项目正在从单体升级为微服务而忧心;或者你在实践微服务过程中手忙脚乱,本文都是你不容错过的

微服务配置中心完全解读

本文作者:风卿,Nacos社区committer.在撰写这篇技术选型的文章之前,是比较犹豫的。因为,以其中一个开源项目开发者的身份,去写一篇三个开源项目的对比,即便很克制的去客观的比较,也很难有信服力

可伸缩的微服务告警系统设计指南

Uber的软件架构由成千上万的微服务组成,有赖于此,我们的团队可以快速的自主迭代并支撑公司的全球扩张。这一架构支撑了大量的上层解决方案,如移动应用,内部基础设施服务,以及拥有复杂配置的产品,相关配置会

再见微服务,从100多个问题儿童到一个超级明星

翻译| 马岛本文翻译自AlexandraNoonan的 GoodbyeMicroservices:From100sofproblemchildrento1 superstar。内容是描述 Segmen

微服务?数据库?它们之间到底是啥关系?

过去几年来,“微服务架构”这个术语持续火热,它描述了一种将软件应用程序设计为可独立部署的服务套件的特定方式。尽管这种架构风格没有确切的定义,但围绕业务能力,自动化部署,网点智能以及语言和数据的分散控制

微服务治理与统计分析

转载本文需注明出处:微信公众号EAWorld,违者必究。引言:微服务架构下,服务拆得越细,服务的粒度越小,可组装性就越好;与之相对的服务之间的调用关系就会变复杂,为了保证服务更好的运行,需要对这些服务

金融行业微服务架构解析

转载本文需注明出处:微信公众号EAWorld,违者必究。引言:对于微服务,每个人都有自己的理解,与互联网企业的大量落地相比,微服务在传统金融行业还没有普及,这首先是传统金融行业线上系统需求更新和版本迭

美团大规模微服务通信框架及治理体系OCTO核心组件开源

微服务通信框架及治理平台OCTO作为美团基础架构设施的重要组成部分,目前已广泛应用于公司技术线,稳定承载上万应用、日均支撑千亿级的调用。业务基于OCTO提供的标准化技术方案,能够轻松实现服务注册/发现

同程旅游微服务最佳实践

本文首发胖波聊架构界,微信公众号:xiaobo2as本文概要导言微服务拆分的四个维度微服务应该如何维护版本如何从单体架构平滑过渡到微服务结语一、导言同程微服务从立项到实施推广已经走过了整整两个年头,从

从300万行到50万行代码,遗留系统的微服务改造

在传统企业甚至互联网企业中往往存在大量的遗留系统,这些遗留系统大多都能够正常工作,有的可能还运行着关键业务或者持有核心数据。但是,大部分遗留系统通常经常存在技术陈旧、代码复杂、难以修改等特点。笔者曾经

百亿流量微服务网关的设计与实现

本文从百亿流量交易系统微服务网关(APIGateway)的现状和面临的问题出发,阐述微服务架构与API网关的关系,理顺流量网关与业务网关的脉络,分享API网关知识与经验。API网关概述“计算机科学领域