前言

  本文于 2022.6.29,首发于ITPUB 官方公众号,作者陈珙,未经授权禁止转载。如需转载,请联系 ITPUB 公众号。

  上星期,我发了篇文章——《重新理解微服务之它还那么纯粹吗?》,从微服务从他的过去、本质出发跟大家分享自己一些见解。此篇文章会从4个争议比较多的微服务话题出发,再跟大家再分享一二。

  原本两篇文章是以一篇来写的,但是原字数1万7千多字,经过和DTCC的韩老师沟通后,最终拆成了两部分。

写在前头

  大家曾经有没有遇过日常技术交流的时候,会讨论某某技术之间的关系是什么,某些技术是否应该用到微服务。我相信热爱技术交流的您,就算不是在微服务这里领域,或多或少都会跟其他同行会做一些争议话题的探讨,而且我敢肯定这些讨论绝对热火朝天。

  今天我想从微服务的4个比较火热的话题进行出发,与大家分享我对微服务的一些个人见解,这4个话题分别是:微服务来带的新问题、微服务与SOA、微服务与DDD、是否有必要引入聚合层。这里部分话题,在业界会存在一定的争议性,例如DDD的引入、微服务与SOA的关系。

  一千个人眼中有一千个哈姆雷特,不同的人以不同的视角去看待这些问题,都会拥有不同观点与答案。观点上,咱们求同存异,不盲目遵从别人的想法,也不自以为是的把自己当成标准

  当然了,我并不会为了个人见解而故意制造观点与话题,更不会把我所有的观点当成一个“所谓的”标准。因此在该篇文章,我会把多处理收集的资料梳理好放到文内,有理有据结合自己的见解与大家分享一二。

  这些内容可能是大家日常容易混淆的,也可能是大家多次纠结不知道如何做出选择,因此我希望通过我该篇文章的分享,能给大家带来新的观点上的碰撞,或是见解上的共鸣。

微服务带来的新问题

  做技术选型就如网上购物一样,即使知道了的优点,还得看看的差评。我们得多方面评估,事先知道团队与业务是否能抵御与承受“坑”的风险

  既然任何一样技术都无法成为软件工程的银弹,那么必然解决了某种问题的同时也会带来一些新问题,微服务也不例外。我回了下当时我实施时的难点确实有不少。不过,我个人认为微服务给我们带来最核心的问题主要有三点,两文化一思维

  • 自动化文化
  • 可观测性文化
  • 分布式系统思维

重新理解微服务之它还那么纯粹吗?-LMLPHP

  上面这三个问题,每个的内容单独拿来出讲的篇幅都足以出一篇完整的文章甚至是书,基于此我会挑一些重点和大家分享。当然,几乎部分的文末我会放入相关内容的文章外链,如果大家有兴趣可以自行扩展阅读。

自动化:避免重复的人力劳动

  任何的架构模式也是需要同等的开发模式与之配合,随着应用的拆分后服务的数量由量变引起质变,因需要接受自动化来代替从前的人工处理,包括服务的部署、服务注册发现等等。自动化是软件工程的其中一种处理手段,允许团队采用主流的工具、流程形成一套自动化机制,从而减少重复性工作、减少人力干预的不确定性因素。

  这里说说我对软件工程的理解:通过多人协作、有目标、有步骤、有计划的并使用科学方法论指导开发与维护程序的这个过程,也可以换成一条公式表达:软件工程 = 工具 + 流程 + 模式。

 重新理解微服务之它还那么纯粹吗?-LMLPHP

  无论是我们讨论的这些“事”技术工具还是流程制度都是需要人(团队组织)的参与,的延申就是团队与文化,就如上述所说的软件工程是多人协作的工作,只有当然团队目标一致,共同负责承担团队的项目,共同接受同一种文化才能很好的实施自动化。

  我简单举个例子:如同多匹马拉车一样,只有它们都有共同的目标的时候才能快速拉车到目的,如果们一匹向东一匹西,只会让马车无法前行甚至四分五裂。

   说到这里有些人觉得疑惑,自动化这种能给团队省时省力、减少重复工作量、增加幸福度的技术难道还有人或者团队会抗拒的?是的,还真的有。

  我曾经就接触过几个团队的Leader他们的团队都是推行自动化失败了,失败原因就在于成员不配合,成员拒绝配合的理由是:没有自己亲手去做总觉得机器不靠谱。我们先忽略他们的想法错,回到团队与文化,从上面可知,统一团队的目标一致性是有必要的,作为技术领导者推行优良的方案是我们的职责之一如果团队成员无法配合导致推行受阻,我们一共有三种应对策略激励、考核和逐步试行

重新理解微服务之它还那么纯粹吗?-LMLPHP

  如果有条件的公司可以设置奖金激励,如果有绩效考核的可以将自动化的实施纳入考核目标,如果这俩都没有,那就选取团队里愿意改变的同事牵头试行,假如使用过后都说好,那么更有说服力。 

  这部分就说到这里吧,基于此话题的内容比较多广而泛,篇幅有限,这里分享一篇我自己曾分享过的内容.Net微服务实战之DevOps篇,如有兴趣的朋友可看完整篇文章后自行有选择性、针对性地扩展阅读。

可观测性提高团队对系统运作的信息量

  如果自动化是给团队带来稳定性减轻工作量,那么可观测性就是提高团队对系统运作的信息量。建立可观测性的这项工作虽然无法直接给系统带来健壮性,但能够使我们通过这些信息充分了解到系统正在运作的情况,以至于最大程度做出最合适的定位、判断与决策

在单体应用的场景下,我们也是需要可观测性的,但是单体的架构相对简单项目调试也更加便捷,无论是从复杂度和规模的角度来看,单体跟微服务相比都要低不少,也因此单体对可观测性的需要相比于微服务显得没那么重要。

  而我们只要进行了微服务实施后,因为应用被拆分成了细粒度,从而导致了架构从量变引起质变,这个时候可观测性的作用在微服务场景下被“无限放大”,也因此我们利用"可观测性"给与我们提供应用与服务器的监控、快速跟踪与问题定位的功能。

可观测性——可以由系统的外部输出推断其内部状态的程度,在软件系统中,可观察性是指能够收集有关程序执行、模块内部状态以及组件之间通信的数据  
06-29 18:34