从保险系统升级谈微服务架构的弊端

引子

这几天最热的一个技术新闻是 《GitHub 前 CTO：全面微服务是最大的架构错误！网友：这不是刚改完 GitHub 吗》

这位前 CTO Jason Warner 在推特上表示：“我确信过去十年中，最大的架构错误之一就是全面使用微服务”，并建议单体应用到微服务的的规划顺序应该是：单体应用->应用->服务->微服务

正好去年我负责并参与了一个保险系统的升级工作，就是从原来的单体应用系统升级成目前流行的微服务架构。实施期间踩了不少的坑，且在后面运维过程中遇到不少实际的问题，这里复盘一下自己一些当时不成熟的观点。

微服务架构体系的优点，本文打算一字不讲，因为任何一本书籍教程里、任何一个系统升级 PPT 中都会把微服务的优点说的非常的全面和准确，肯定要比我总结的更好，但任何事物都是有一利也必有一弊。

首先我非常认同 Warner 的观点：如果是一家 5-50 人的公司，只需坚持使用单体；服务越多，维护的风险就越高。

遇到的问题

回到我参与的保险系统的升级工作上来，当时从项目立项到系统上线，历时半年有余，上线后无论是功能体验还是速度感受都要远远好于原来的 SSH 架构系统，并且与外围渠道的对接效率有了大幅度提升，好评是有的，结果也是满意的。这里只从开发的角度去吐槽一下客观存在的问题：

系统被搞的复杂了，至少部分简单问题被复杂化了

很多时候，我们在“高并发”和“大数据”的概念下把软件系统变得越来越复杂，而为了解决复杂性，又不得不使用更多的微服务或者其他软件工具，且投入更多的运维成本。实际上我们一般采用的都是各大厂的开源框架，是经过很多版本迭代和应用实践的集成品，代码性能其实是有大量冗余的，而前面的两个概念，通过硬件解决要比通过代码升级便宜的多的多，而且效果更明显。

但是无论是企业还是开发运维人员更愿意提升“软实力”。

一、微服务拆分的太“微”了

微服务的‘道’是在 服务 这个词语上，但是‘技’却在 微 这个字上，越看似合理的服务拆分就会拆的越小（代码的设计之道就是要做到单一性）。我们当时系统升级后的微服务有 40-50 个服务之多，一张保单的保存、计算、提核、核保到保单的生成都有单独的服务，如果被批改的话，又有这么一套单独针对批单的服务。一张投保单数据在不同的“微服务”里会有多种不同状态，那么为了解决单号重复的问题，又不得不把生成保单号码的功能单独作成了一个服务。

因为过多的微服务化，导致有些单个微服务本身，已经退化为功能代码而不是业务代码，在实施上线的过程中，大量的开发和测试工作集中在了如何去兼容上下游的系统。

一个承保系统的核心服务简单划分大致如下图所示：

合理拆分最好是按照数据库进行拆分，先分库再谈服务，实际是可以大致分为下面几个相互隔离的库：产品数据库、保单数据库(投保单、保单、批单)、规则文件库、渠道配置及报文库

这虽然不是“微”服务，但是这是服务，是按照业务模块划分的服务。

二、运维和维护系统的灾难

软件开发的 80%的成本来自于维护。

我从网上随便找了一张微服务的架构体系，来感受一下：

一个运维人员要熟悉并了解的技术栈从原来的单体应用成倍的增加，特别是在只有十几名开发人员的情况下，贸然使用微服务绝对是疯狂的行为。而我当时的那个运维团队，40 多个服务可能只交给三四个人来开发运维。

DevOps 就是开发运维要全会，用到的技术也越来越多，从编码到发布，从注册到治理，从编排到链路，工具是越来越多，每一个工具都说自己将原来繁重的任务变得简化了，配置化了，这无疑如同学校的减负一样，每课老师都把作业量控制在了合理的范围内，但是架不住一天上五科啊，可能还附带一个手抄报的作业，

特别是开发一个需要跨多个服务的功能，需要做更多的工作，这对开发人员来说是一个噩梦，尤其是处理问题跟踪难度飙升，即使借助工具，快速定位了问题代码，但是原因可能是另外的服务引起的，而另外的那个服务可能是其他人开发的，这种倍数级的级联是很可怕的。并且这也导致了下面的一个严重问题。

三、变得越来越糟糕的代码

先要明白，人都是懒惰的，能少写代码就少写代码，面对跨服务的情况，如果没有严格的开发规范和代码审查，很多人会选择在当前服务中实现另一个服务的功能，也可能是因为对系统架构体系缺乏了解，每个微服务边界模糊不清，随着时间的推移，代码会变得越来越耦合

因为我们的团队属于外包服务，团队内部开发能力参差不齐，且因人员流动频繁，导致大多数开发运维人员，业务知识有限（相信这个问题是大多数外包团队面临的共性问题）。运维阶段大量的时间用来讲解服务架构和业务培训，但是大多数人还是管中窥豹，难见全貌。

正常一个单体应用的系统，在无大牛无技术性领导的情况下，累计到第 5 年，就会会变的难以维护，如果是微服务架构代码，这个上升曲线会陡增，第三年就可能很难看懂了。

这不是在吐槽当时的团队人员，因为无论承认与否，几乎是所有的(长期运维的)业务系统必然走向的一个结果。相信大多数的一线开发也都接手过别人的“屎山”代码。

最后

微服务的起源是因为业务系统模块庞大，逐渐的每个模块都被抽离成单独的应用系统，并且对应了专门的开发人员，系统和系统之间交互就需要接口、RPC 等方式来进行，慢慢的就衍生出了微服务和各种运维管理工具。

微服务架构的升级，从来不是技术的要求，是业务模式和商业模式的变化带来的需求。服务的拆分肯定会让业务组合更灵活，反之市场业务模式的快速变化，必然要求 IT 服务快速的跟上。

• 采用微服务架构前一定要先分析目的是什么？要解决什么问题？微服务是否是最优方案？

• 还要考虑后期成本，因为业务规模没有上去之前(其实中小保险公司的业务量还达不到应用的理论性能上线，优化优化代码和升级一下硬件，可能是最务实的方案)，升级系统只会增加成本，活是越干越多的，有了电脑难道就比以前用算盘的时候轻松？

• 最后分析微服务划分的依据是什么，是按功能还是按业务? 先分库还是先分服务？一个完整的业务链条有无必要按照步骤进行拆分? 都要考虑明白。