大家好,欢迎来到万猫学社,跟我一起学,你也能成为微服务专家

在了解引入微服务架构的时机之前,架构设计时一般需要遵循的三个原则。

架构设计三个原则

架构设计一般需要遵循以下三个原则:

  • 合适原则:合适优于业界领先。
  • 简单原则:简单优于复杂。
  • 演化原则:演化优于一步到位。

合适原则

我们一般都有很强的技术情节,做架构方案时,总想着挑战自己,做一个很牛的架构,但如果设想超越了现实,最后很可能会失败。

即使我们的设计再好,能为公司打下很好的基础,但公司的实际环境如何?能否很好的落地?如果没有那么多人,却想干那么多活,肯定失败。

优秀的架构其实都是逼出来的,业务发展到一定阶段,量变导致质变。没有那么强大的业务场景支撑,失败的概率非常高。

简单原则

很多人评价一个设计方案水平高低时,很喜欢看复杂度,越复杂的系统,出现故障的概率越高。

应谨记KISS(Keep It Simple, Stupid)原则,大多数系统的设计应保持简洁和单纯,而不掺入非必要的复杂性,这样的系统运作成效会取得最优。

演化原则

对于建筑来说,永恒是主题,对于软件来说,变化才是主题。

架构设计时要时刻提醒自己不要贪大求全,或者盲目照搬大公司的做法,应认真分析当前业务的特性,明确当前业务的主要问题,设计合理的方案,快速落地以满足业务的需要,然后在运行过程中不断完善架构,不断随着业务演化架构。

什么时候引入微服务

微服务架构虽然看起来非常美好,但是也是有很大附加成本的。

通过上图可以看到,横轴是复杂度,纵轴是生产力。当软件的复杂度很低的时候,单体架构下的生产力是要高于微服务架构的,但随着复杂度的不断增加,无论是单体应用还是微服务应用的生产力都会下降,只是微服务架构的下降会相对缓慢一些。

因为在微服务架构中,我们的系统是由很多的小的服务组成,每一个服务都很小,相对简单,技术栈也很独立。这样做局部的变更也会更加容易,随着系统复杂度的不断增加,微服务的优势也就慢慢地体现出来了。

怎么引入微服务

在合适的项目,合适的团队,采用微服务架构收益会大于成本。微服务架构有很多吸引人的地方,但在拥抱微服务之前,也需要认清它所带来的挑战。需要避免为了“微服务”而“微服务”。

Martin Fowler(马丁·福勒)提出的单体架构优先(Monolith First)的思路,我们可以了解一下:

不推荐一开始就全盘直接使用微服务架构,因为微服务需要前期基础设施的投资,复杂性很高,如果对问题领域并不是很理解,一开始用微服务,很难去划分服务的边界,生产力反而会比较低,而且花了很大精力进行开发,产品并没有被市场验证过,有可能会失败,所以这个选择风险会比较高,所以推荐的是单体架构优先。

先从单体架构运用做起,这样成本低,团队成员也比较少,无须太多研发投入,就可以快速迭代并交付一些基本的功能,这样也可以赢得更多的时间去探索业务领域的复杂性,对业务领域的边界会有更深入的理解。可以考虑引入部分合适的微服务架构,原则是边界已经很明确的小范围领域,或是对已有系统进行改造或,逐步探索及积累微服务架构经验,而非全盘实施微服务架构。

随着应用越来越成功,用户越来越多,系统复杂度越来越高,就会出现单体架构应用和团队规模之间的矛盾,生产力会随着业务复杂度逐渐降低,这时再逐步的进行微服务化的拆分效果会更好。

最后,感谢你这么帅,还给我点赞


《从零开始学微服务》总目录

  • 【从零开始学微服务】01.微服务的过去与现在
  • 【从零开始学微服务】02.初识微服务
  • 【从零开始学微服务】03.软件架构的演化过程
  • 【从零开始学微服务】04.微服务架构的特点
  • 【从零开始学微服务】05.微服务的优势和不足
  • 【从零开始学微服务】06.微服务架构的建设思路
  • 【从零开始学微服务】07.微服务常用的开发框架
  • 【从零开始学微服务】08.引入微服务架构的时机