谈谈架构和微服务<一>

用户头像
Gabriel
关注
发布于: 2020 年 06 月 28 日
谈谈架构和微服务<一>

不知从何时起,与同事,面试者,面试官谈起架构理念,总是绕不开微服务。甚至有时候听到这三个字的时候,脑壳会痛,相似的还有中台, 总觉得是旧瓶装新酒。 当然此时的盛行是有其原因的,猜测主要原因是容器化的盛行。



架构和微服务的定义:



能给出合适的定义才能表明一个人真正理解了所描述的事物。



架构:



按照一定的方法设计出来,把系统划分成颗粒合适边界分明,复用合理的模块。这里的关键词是颗粒合适边界分明合理复用



微服务:



颗粒度较小的架构,关注点是颗粒度相对较小。



为什么要存在架构和微服务架构:



大部分事物存在的理由都是带来了价值或者解决了问题,架构或者架构师存在的意义也是解决问题。合理架构带来的直接帮助是节省了因为改动引起的工时变化。 (改动 这个关键字圈出来。) 当然还有一部分是带来性能的提升或者是安全性。



假设架构师或者业务的owner对业务没有太多的前瞻,那么业务初始的必然是一个大应用。随着时间的推移会慢慢发现大应用的问题:



  1. 一个团队难以维护这么的系统,理解和沟通麻烦,出现边界不清大量扯皮。



很多人都会说用写文档解决问题,一方面高强度的开发,和利他主义薄弱的个体难以主动维护文档。另一方面读文档也存在理解偏差的情况。所以一个系统要让别人理解,最好设计本原就是好理解的。



2. 系统之间互相影响,工程效率/测试效率,安全性也受到影响。



一个核心系统与非核心系统,无论是发布还是出现问题的报警处理级别都是不一样的。因为一个后台管理系统发布或者出bug导致支付业务挂了, 就会让外界感觉匪夷所思。因为要保证核心功能不受一些非核心的影响,每次发布重新覆盖所有流程。



所以我们出现微服务就是为了解决上述问题。



如何指导架构:



至此为止,我们可以把微服务架构当成一种边界清晰,颗粒合理的架构方式,以下的架构方法论主要会围绕微服务来讲。



架构的方法论非常之多,然后我们做任何事情都要找到第一性原理。在软件生命周期中,如果它一直是一尘不变的,那么他设计成啥样都无所谓,因为测试完成交付就可以了。但是如果有变化,意味着我们会因为改动而产生bug, 因为改动而发现代码无法维护。



所以我们设计类,应用,系统架构遵循的核心考量标准就是 在有变化的前提下,能否更轻易的应对变化。



在有变化的前提下:



一个模块或者系统如果不可能发生变化,或者频率极低,就需要考虑是否需要为应对变化而付出成本,因为要应对变化必然要有一些开闭或增加理解成本和编码成本。 就类似spring的code就非常复杂,作为一个开源工具,必然需要更多的extension。但是如果一串几乎不改的业务代码有非常多的设计模式,看起来层层叠叠,那你肯定想杀了他。



再多说几句,其实设计模式这本书本身不是指导程序员开发的,而是一本通识类的书,告诉你某种写法叫啥。当某段程序需要变化的时候,必然会去想怎样能更好应对变化,而不是想起自己有个锤子,看地球都是钉子。



能否轻易应对变化:



这时候我们可以一生而二了。轻易应对变化就是修改一个模块时,需要做到高内聚,低耦合。它的变化封闭在本模块中这就是所谓的高内聚。如果你修改了一个模块对其他模块的影响很小那就是所谓的低耦合



更具体的措施:



从更宏观的多个微服务来看,我们需要做到 边界清晰,颗粒合适,复用合理。



边界清晰:



为啥要边界清晰:



边界清晰的首要好处是低耦合。如果你的应用架构图设计看来是一个网,那大概率是不太合理,因为这样应对变化不太灵活。主要的可能是本该在一起的功能被拆开到了其他系统中。



怎样做到边界清晰:



用领域建模去建立业务模型, 如果是DownTop根据业务用例,分析动名词去提取构建业务模型。 例如男孩小明今年9岁,他去超市买了瓶水这个用例我们可以分析出 领域小孩: [性别,年龄]。 超市:[商品]。



TopDown是为了解决现有问题,主要还是宏观的问题论,不再这里讨论。



颗粒合适:



为啥要颗粒合适:



  1. 过分的拆分微服务影响性能,从进程内通信变成了RPC通信。

  2. 如果团队人数过少,维护成本特别高。最极端的情况一个人兼任owner,加另一个系统的备。

  3. 系统过多,监控运维成本也很大。



怎样做到颗粒合适:



根据团队去划分,让团队内的沟通更专注。系统的数目绝对不要超过团队的人数。



合理复用:



为啥要合理复用:



首先微服务强调的是隔离,因为很好的隔离性才能让这么多的服务稳定的跑下去。但是一个系统不可能没有重复模块。那我们反证一下不合理的复用有什么缺点:



完全不复用: 系统有很多冗余代码,会出现散弹式的修改,更有可能是忘记修改。



不灵活的复用: 打成jar或者dll,被多个系统依赖。每次改动jar的逻辑,为了同步改动发布多个依赖应用。



独立应用隔离: 运维维护成本超级高。



怎样合理复用:



多份冗余代码: 对于几乎不变,依赖方少于3个的或逻辑可能出现分裂的模块。



打成jar或者ddl: 对于功能几乎不变,且依赖方相对较多的功能模块如工具类。



下沉成应用:功能逻辑被多处引用,且逻辑变化频繁。



越是依赖多的,越是改动多的,复用方式就要越灵活。



下一篇我们会讲如何应用领域建模的方式来应对实际场景



发布于: 2020 年 06 月 28 日 阅读数: 53
用户头像

Gabriel

关注

每一段不曾起舞的日子,都是对生命的辜负 2020.04.11 加入

美团网/阿里巴巴

评论

发布
暂无评论
谈谈架构和微服务<一>