不要迷信微服务,但也不要放弃对微服务迷恋与追逐

        微服务的概念与早期IBM的SOA的概念(08~10年做项目基于上都是套用SOA),有着异曲同工之处,都是基于模块化的思路来实现高内聚低藕合的系统设计理念,只是它们的实现方式不同而已,比如基于EJB(RMI)来实现SOA,基于Spring-cloud/dubbo(Http/RPC)来实现微服务。微服务的概念从提出的那一刻起,已经在技术圈火暴到现在,算是比较成熟的系统设计与开发理论。微服务简单点说就是通过开发一组小型的服务(模块)来构造一个独立的应用系统,每个小型的服务都运行在自己的进程中,通过特定协议的API来相互通信,达到模块化应用系统的目的。从微服务的概念,可以看到有如下的优点:

1、 模块化开发与维护

       业务拆分成不同的小型服务,每个小型服务只专注特定的业务(比如商品可为一个小型服务)领域,实现业务功能的高度集中,降低传统业务堆积在一起,难以维护的程序,方便对业务的理解、运维、调度,提升服务的可维护性。(前提是业务和技术要有高度,能很好地划分业务领域与边界,不然会越做越乱)

2、 故障隔离

       某个小型服务宕机,不会影响到其他服务继续使用,避免了单体应用宕机后,系统不能使用的情况。(前提是要做好服务与服务之间的融断机制,如果没有处理好融断机制,一样可能引起整个系统的雪崩)

3、快速响应局部需求/修复的上线

       基于小型服务的特点,对于线上的问题,或者特定业务领域的需求的开发,可以做到快速的开发与上线,而不会影响到其他小型服务的继续使用,有别于传统的单体服务,需要整个系统重测及停机上线。(前提是需求不会涉及到整体的功能)

4、技术栈不受限制

      微服务都会有服务发现与注册中心,来负责调试不同的小型服务,只要小型服务的数据通讯协义是共同,可以采用不同的技术栈来进行开发,如java、.net等,也可以采用不同的数据,如mysql 、oracle、SQL Server等。(前提是要有统一架构标准)

       基于微服务的优点,在公司的很多项目中,就在计划及实施微服务,解决单体项目在业务不断扩展,功能不断堆积后的开发,上线及运维的困难,通过不断的研究与测试,开始从与业务无关性的基础服务迁移到微服务体系中,通过一年左右的时间,实现了Java体系的都所系统微服务化,从效果上,确实验证了微服务的优点,服务化后各小型服务专职特定的业务,降低互相依赖的关联,开发人员专注度更高,在当时确实提升了系统运行的稳定性,虽然在过程中不知踩过多坑。

        但随着业务的发展及功能的越来越多,小型服务越来越多,微服务的优点是需要付出代价的,它的基础是要有一定的团队规模(与服务数量有关)、运维人员、产品与技术相结合的高度才能保证良好的运作,适用于成熟的系统平台,不适用于项目初期的快速迭代升级。总结来说,有以下的问题:

1、降低开发效率,可能增加开会周期

        拆成多个小型服务后,可能一个需求的开发,会涉及到多个服务的同时开发,这个在当初的商城开发中经常遇到,尽管当初的开发人员还是比较多,但效率还是低下,微服务是告别直接查询数据库,采用标准协议来通讯(API接口),也就是接口对接,需要多方人员进行沟通确认(沟通成本),结果核对(对接成本),可能还会一份数据存在多个数据库中,通过接口同步来同步去。这个就好比去市场买菜,如果一个去,直接按清单买就完,如果分派多个人去,要先跟每个说买什么买多少,买回来后又要核对一遍。

2、产品与技术的高度

        如果产品经理与技术架构不能很好的配合,思路碰不到一起去,那是没办法实施微服务的,最终就是边界不清,没办法将要开发的功能落实到各个小型服务中,反而会确觉这个不适用,那个不适用,不如重新开发一个。到最后会发现,各个服务之间调用比蜘蛛网还要复杂,可能会导致需求都改不动代码,还不不拆时好处理,变得难维护。

3、数据不一致问题(业务数据算多算少的问题)

        相当大家都有这样的经历,在传话的过程中,信息会变多或变少,从上往下,如果不记录,路径越长,信息会越来越不准确。实现微服务也有这样的风险,服务拆得越多,调用的路径越长,数据的不一致性会越来明显。但在单体项目中,这种情况会很少,它可以通过事务来统一处理,微服务难通过事务来保证,它的服务调用都是异构环境,一般只能采用数据最终一致性的策略来保证,但这个过程需要架构及开发人员有高水平,不然就会导致业务数据重复,或者丢失,严重的会造成公司的损失(比如处理钱相关的程序)。

4、沟通与人员成本

       拆成小型服务后,需要有匹配的开发人员,也有对应的运维人员,服务拆得越多,需要更多的服务器资源来运行;相对于单体项目,人员的成本会高很多。

5、维护成本加大

       服务拆分得越多,维护的成本就越大,需要增加对各种服务的监控、事件的预警;升级改造也会增加工作量(涉及大量服务更新时)。

6、问题排查困难

        在传统项目中,可能找问题只需要在一个日志文件中就可以查找,但如果拆成微服务后,用户的一次操作,日志可能会分布在多种服务的多个文件中,在系统出问题时,排查起来的复杂度变高,时长会变长,在评估问题时,需要找到每次服务调的输入输出,不然难分析问题。(但这个不是不能解决,可以部署链路日志收集程序来采集所以的日志,汇总起来供查询)。

7、硬件成本增加

       拆成多个小型服务后,需要更多的服务器资源来支撑其运行,如果资源不足,是无法运行的,每个小型服务的运行,是要有一定的资源基础,还有运行产生的日志会占用资源。

        这里没有说单体项目有多好,微服务有那些不好,是没有确定的说法,它的存在自有它适用的场景。一般在业务探索的阶段,以快速响应市场需求的变化,是不建议采用微服务,除非团队成员够支撑,不然开发效率反而会降低。试想想,在项目的试错阶段,就去搭建一个大型公司的微服务架构,可能是浪费资源,而且也不能及时显应变化,需要大量的团队成员来维护,不然效率会很低下。如果平台成熟定向,是可以按微服务的方式来运作,按不同的平台功能分支进行扩展,降低具体某个项目的复杂度、维护量,形成多个小型服务,但也必须在产品与架构达成一致的前提下进行。

        架构的选择,是平台/系统在发展不同阶段的选择,不能为了架构而架构,过早的去优化架构,在后面都会形成技术的债,可能会让进度陷入困境,但做平台/系统开发,也不能放弃对先进技术的研究与实践,这也就是我说的“不要迷信微服务,但也不要放弃对微服务,中台的迷恋与追逐”。

本文链接:https://www.jhelp.net/p/tDYPBnJvmA2wVcnw (转载请保留)。
关注下面的标签,发现更多相似文章