【从零开始学微服务】08.引入微服务架构的时机

阿里云国内75折回扣微信号：monov8

阿里云国际，腾讯云国际，低至75折。AWS 93折免费开户实名账号代冲值优惠多多微信号：monov8 飞机：@monov6

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

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

架构设计三个原则

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

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

合适原则

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

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

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

简单原则

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

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

演化原则

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

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

什么时候引入微服务

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

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

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

怎么引入微服务

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

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

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

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

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