|
|
51CTO旗下网站
|
|
移步端
  • 为什么我们要放弃迁移到微服务?

    近些年我们开发集团在开发计划中有一度小停顿,艺术部门认为现在是将采用从单体架构迁移到微服务的超级时机。

    笔者:杨峰 译 来源:Docker| 2020-01-18 09:35

    近些年我们开发集团在开发计划中有一度小停顿,艺术部门认为现在是将采用从单体架构迁移到微服务的超级时机。

    图表来自 Pexels

    历经一番月的准备和调查,咱们取消了迁移,仍然使用单体模式。对我们而言,微服务不仅帮不上忙,反而会影响到开发计划。

    咱们了解微服务大约是在一年前,但是很奇怪地意识他并不适宜我们。资本篇文章把我们的阅历写出来,可能会对大家有借鉴意义。

    意识问题以及早期妥协

    咱们严重依赖第三方

    咱们的使用是结合外部现有产品和工作规则给用户展现一个温馨界面的 UI。我家是一家 UWP App,看台有相应服务在先后三方域和我们中间交换数据。

    对第三方的依赖严重影响我们挑选微服务。例如,使用经常要在不同域之间转换功能,有效第三方域看起来像是完整不同之一个域,如果在我们中间有一度单一服务场面还不算太糟。

    然而,任何域交换在诠释成多个微服务过程中就看起来很奇怪了。

    是咱们的微服务跟第三方的说明不同吗?咱们复制了方方面面服务的左右端需求吗?还是我们分解了上下一心之微服务,仍然需要一个微服务从第三方获取信息?整整这些题材看起来都跟微服务规范相背离。

    咱们和程序三方协作很紧密,经常一起协作发布版本。微服务的功利在于每个团队都得以不受影响独立发行服务,而跨公司合作则失去了这种好处。

    微服务另外一个好处在于,每个团队只要求完整设计自己之工作问题。而我辈,表现一个和程序三方完全独立的合作社组织,这种重构看起来不中用。

    咱们决不能有效分离微服务

    咱们扎实找不出相应从哪个单体应用下手。于是乎我们在域模型之间连线,以决定要创造哪些微劳动。

    然而,一旦这么开始做,意识很多共享业务逻辑影响着微服务域的分割。如果将微服务划分的更细小,只能带来更多的耦合关系,大街小巷都要求消息总线,信息可能会出现大爆炸。

    原因在于我们的单方面体式应用是为一个作业逻辑服务的。咱们为客户方便创建了跨域和组的许多工作流,实质上,UI 在过去四年中就是将各种东西整合到了共计。

    此外,咱们还误解了微服务如何把隔离,以及低估了劳动之间正确边界选择的重大。

    唯一能完成的就是为了贯彻一个标准功能,故而需要将全部相关微服务同时升级,由此要求每个微服务都不能把某个单独团队拥有。

    共享微服务

    咱们大约有 12 个开发人员分布在两个效益团体和一个支持团队。上班波动性很大,没有专职负责组织。整整团队同时接触同一批代码很正常,决不能将某个微服务指定给一个团队。

    考虑架构时候一定要记得 Conway's Law,他意思是软件架构会模仿组织和组织架构增长。

    微服务架构对于不同团队负责不同工作逻辑是比较有效的,然而,共享代码功能的上班模式最好采用单体式架构。

    平台并没有准备好

    各族问题意味着至少六个月内,要求在 IIS 内并行运行微服务和单体式应用。

    咱们不会访问与微服务相关的工具,如容器、Kubernetes、劳务热线、API 网管等,也就意味着与其他微服务之间通讯有很大障碍。

    故此,咱们决定每个微服务都复制与存储层转换相关读服务的共享逻辑。因为不能正常拆分服务,也就意味着必须承担大量复制工作量。

    例如,对于某个复杂而且基础的工作逻辑,必须复制黏贴并维护至少 4 个计划中的微服务。

    没有未来清晰图景

    付出集团只有六个月内粗略的联想,而且业务更改也很频繁(工作更改需求也是普通的作业),该署让微服务化更加充满不确定性,因为即使在短期也无从预知会出现什么链接。

    微服务之间的纷繁会增加吗?五颜六色了几个月分离的劳务会返回过去吗?尽管我们今年早些时候做过一些 PoC,但是因为业务需求之转移不得不放弃。

    架构紧耦合

    咱们只有一度很窄的年华窗口,刚好能把单体式应用分解成排出来的微服务,而且没有冗余时间应付可能出现的变动,也没有 Plan B,咱们把自己给卡住了。

    因为我们在准备阶段就发现了众多问题和挑战,更别说实施阶段了,付出集团非常有压力。

    缺乏经验

    考虑到风险和时间压力,而且架构师和实行专家也都没有其他特殊经验,增长没有正式工具能用,咱们只能靠自己来实行,该署都更加恶化了事态。

    和任何微服务大拿沟通后,她们也都发出了众多警告,并送出了许多以前并没有的架构建议,指出了俺们在域模型之间画线的程序。

    到当前结束,出于时间紧任务重,咱们的准备包括了很多不同于标准微服务的折衷方案。

    因为缺乏专家,这看起来更像一枝不归之路,付出集团越来越焦虑。

    再次拷问我们的对象

    只是解决了痛点

    一旦前方布满了艰苦,就失去了目标,咱们暂停下来,得知我们并没有搞清楚为什么要这样做。

    咱们没有列入痛点,而且不知晓这样做是否可以解决痛点。更甚,微服务有可能会给咱们带来新的问题。

    咱们开始反思,咱们从中会获得什么好处?能解决什么问题?咱们召开了更多会议讨论它,但一直没有明显的答卷。

    说到底,咱们发现在议论微服务过程中我们忽略了一番很重大的痛点,而且没有足够的年华来解决这个题目,也就是咱们决不能设想微服务或者其它东西了。

    潜在收入是什么

    此刻我们开始反思微服务一般意义上会带来什么好处?

    自治

    微服务使得团队可以操纵全栈提供一个功能。这种区隔会减少不同团队之间协同的用户数,互相不影响中的上班。

    使团队更加专注

    另一方面体式应用中,团组织可以专注于所有任务。而利用微服务后,则是某项工作流程的学者。

    她们会了解自己区域内的工作规则和需要,了解软件栈如何搭建,顶发生改变时会突出有信心成功。

    轻而易举扩展

    有了微服务,可以根据性能需求扩展服务范围。而在一派体式应用中,尽管也得以水平扩展服务,但是不能独立扩展单体应用的模块。

    微服务粒度可以增加或者减少服务能力。也许当发现性能问题时,可以参与其他工作,或者稍微喘口气。

    轻而易举回滚

    每个功能只要求修改单一微服务,而且可以不影响其他组织工作开展回滚。此外微服务还可以减少单一错误对全部系统之影响。

    轻而易举迭代

    如果有一度扩充系统之,每个发布都很花时间并且有高风险,这就是说就要求大量工作处理每次发行时的题材。

    微服务可以减少沟通时间和财力,团组织可以各自确定合适时间。

    利用最佳技术

    团组织依赖微服务可以选择最佳技术方案。而另一方面体式却很难升级。

    轻而易举升级

    大型应用升级都不是一件容易的作业。尤其是中心在多个团体之间协作。相互隔离的微服务可以每次只升级一个劳动,更容易控制风险。

    风险保障

    微服务可以将频繁转移和很少变化的劳务分隔开,调减意外发生之风险。

    零度减小

    无形化服务更容易掌握,而且可以保持设计一致。相比之下来看,另一方面体式应用会因为不同团队的观点不联合带来不一致性。

    优势汇总

    微服务有许多优势。但是我们能从中获得什么?

    末了,对于无法改变或者妥协的架构只能放弃那些优势。咱们失去了微服务带来的隔离性。与程序三方的协作减弱了副服务不相关性中带来的功利。

    衡量

    大炮打蚊子

    微服务也并不都是长项,有一长串需要考虑的题材。

    例如,日志,监督,独特处理,容错,回滚,报道,信息格式,容器,劳务意识,备份,遥测,报警,钉住,工具,共享,文档,推而广之,时区,阶段,API 本子,网络延迟,正常检查,负载均衡,CDC高考,等等。

    如果没有微服务平台,咱们要协调面对所有方面列出来的题材。因为有痛点才要转向微服务,但是不但没法从中获益,还要面对一堆转向微服务带来的题材,咱们是何苦来呢?

    微服务只是名义

    下图是咱们今天单方面体式应用和微服务的对待。架构上来看,新架构很像单体式,各国组件还是紧耦合,也许我们只是用了微服务的竹签。

    另一方面体式一定很差吗

    好像“另一方面体式”就意味着落下,“微服务”就意味着先进。但是从开发集团来看,咱们的单方面体式应用运行良好,基本没有什么问题。

    咱们有很好的 CI/CD 安排,轻而易举配置和回滚。分支和高考策略确保问题都把提前解决。

    似曾相识

    此刻,似乎有些熟悉的感觉。在我以前从业经验也有过类似之阅历,但从没称为微服务,尽管并不完整符合微服务的平整,但是的确解决了问题并带来类似之功利。

    5 个体的小团体带领 200 人口之开发者。这是一番巨大的 C# 使用,简言之 5% 的上班通过单体式共享,其它的共享两节点服务。

    咱们也不希罕单体式,上班开始很慢,编译,高考,架构改变的迅速经常见到不同之同事出现。

    有时候因为一个从未听过的同事辞职了从而延迟了整整项目,艺术创新因为要和万事企业同步需要几个月,Pull 报名要求全体系统批复需又要几个周末。

    同时,有两个服务范围很小,咱们可以很好地掌握、布局、架构它。一旦有性能问题,会怀疑实例数量直到解决底层问题,很少麻烦其他组织。

    咱们组织主导了上下端开发语言的取舍。总而言之,咱们很注意于一个很窄的工作逻辑,每个人都成为了大家。

    艺术之外

    越了解微服务,越发现他不太方便我们。咱们是不是太为了技术而技术了?

    还有好多其他题材没考虑:

  • 有没有专注业务逻辑的团体?
  • 只是能够清晰划分域和微服务?
  • 上班在一切团队之间是否平衡?
  • 团组织负载是否均衡?
  • 另一方面体式困难是否被分解到其它工作中?
  • 复盘

    搬迁到微服务是个大爆炸,大家都停下功能开始想如何分解单体引用,即使前提还不具备。

    新兴证明这不是个好办法,有可能还是个倒退。第一创建所有微服务,下一场设置架构并忽略了集体的架构。

    假如我们开始时考虑团队和工作逻辑结合,等架构成熟,并等微服务自然显现,会更好。而且新的业务需求出现,可以直接被放在一个新服务中。

    强制上微服务,也意味着需要选择每个微服务的大小。一部分文章建议每个微服务至少按照一个团队的支撑设计。其它的则建议越小越好,一旦需要更改,很短时间内就足以做到。

    臭氧层决定按照工作域划分,如果需要再细分。其一决定导致上面出现的题材。新兴复盘时发现如果等待微服务自然出现,他大小其实最适合。

    取消

    随着预定时间一天天临近,咱们组织持续发现越来越多之题材。上点四天后,仍然看不到预期的功力。于是乎召开了一次会议,末了取消了微服务计划。

    代表行动

    微服务的热度消散,也就意味着我们没有做好必要的科研。抛弃了微服务后,咱们也有生命力去调研其他方案。

    说到底,咱们决定在单体应用内部划分成不同档次,更好地划分了架构和耦合关系。

    此外这种架构使得域模型更加鲜明,有效未来考虑微服务更容易。

    总结

    臭氧层上微服务的匆匆决定并没考虑清楚挑战和当前状态。评估后,意识微服务并不适宜我们,要求更多的折衷。

    该署折衷方案把微服务带来的功利都抵消掉了。微服务并不考虑非技术因素,例如团队结构和总分。

    几个月调研后,咱们抛弃了微服务尝试,决定对已部分单体式应用做一些更适于的微调。

    【编纂推荐】

    1. 架构选型,结果什么时候选Redis?
    2. 1GB文本标记只需20秒!拥抱脸团队发布最新NLP工具
    3. 用于软件架构的 C4 模型
    4. 阿里架构师眼中之高并发架构
    5. 京级流量系统架构之如何设计承载百亿流量的高性能架构
    【义务编辑: 武晓燕 TEL:(010)68476606】

    点赞 0
  • 微服务  团组织  架构
  • 分享:
    大家都在看
    猜你喜欢
  • 订阅专栏+更多

    Python使用场景实战手册

    Python使用场景实战手册

    Python使用场景实战手册
    共3章 | KaliArch

    118人口订阅学习

    一步到位玩儿透Ansible

    一步到位玩儿透Ansible

    Ansible
    共17章 | 骏马金龙1

    195人口订阅学习

    云架构师修炼手册

    云架构师修炼手册

    云架构师之必不可少技能
    共3章 | Allen在路上

    33人口订阅学习

    订阅51CTO邮刊

    点击这里查看样刊

    订阅51CTO邮刊

    51CTO劳务号

    51CTO官微

    
       
       
       
        

  •