【放弃微服务，构建单体应用】作者 | GreekDataGuy
译者 | 弯月
出品 | CSDN（ID：CSDNnews）
微服务看似是完美的解决方案 。 从理论上来说 ， 微服务提高了开发速度 ， 而且还可以单独扩展应用的某个部分 。 但实际上 ， 微服务带有一定的隐形成本 。 我认为 ， 没有亲自动手构建微服务的经历 ， 就无法真正了解其复杂性 。
本文是我根据构建微服务的经历 ， 总结出的经验教训 。

文章图片

噩梦般的数据管理
跨多个微服务保持数据同步是一个很大的难题 。
通常人们推荐的方式是每个微服务一个数据库 。 这样不仅可以实现松散耦合 ， 而且还可以让各个服务的团队独立运作 ， 同时不会影响共享代码的协作速度 。
然而 ， 如果两个微服务应该互相同步 ， 但其中一个发生故障 ， 后果会怎样？例如 ， 其中一个微服务更新了数据库 ， 而另一个没有 。 这样的状况会导致数据的不一致 。
根据我的个人经验 ， 跨服务调查数据的不一致会非常痛苦 。 由于错误跨多个服务 ， 因此需要某个人跨多个服务修正错误 。 不幸的是 ， 这导致微服务丧失了其优势之一：每项服务由一个开发团队负责 。
而单体应用则可以通过一个原子事务打包两个数据库调用 ， 保证两个插入操作都成功或都失败 ， 从而轻松防止出现相同的情况 。 十分简单 。
但是对于微服务 ， 松散耦合导致这些操作变得更加困难 。
设置时间更长
构建微服务架构所需的时间比将相同的功能整合到单体应用更长 。 虽然微服务的一个服务很简单 ， 但交互的服务集合比类似的单体应用要复杂得多 。
单体应用中的函数可以调用任何其他公共函数 。 但是微服务中的函数仅限于调用同一个微服务中的函数 。 这就导致服务之间需要通信 。 而构建通信所需的API或消息系统并非易事 。
此外 ， 微服务之间的代码重复无法避免 。 单体应用则可以定义一个模块 ， 并多次导入 ， 而微服务本身就是应用 ， 所有的模块和库定义都在内部 。
微服务更适合大型团队
将微服务分配给每个团队的做法更适合大型工程团队 。
尽管这是该架构的优势之一 ， 但只有当工程团队有足够的人手 ， 可以为每个服务分配多名工程时 ， 这种优势才能发挥出来 。 缩小代码的范围 ， 可以让开发人员更好地理解代码 ， 并提高开发速度 。
然而 ， 大多数创业公司并没有这样奢侈的资源 。 创业早期 ， 公司的资源往往不足 ， 有些工程师需要负责所有的服务 。 不幸的是 ， 开发人员的思维需要在多个应用之间来回跳跃 ， 因此会导致生产力低下 。
此外 ， 跨多个陌生的微服务调查 bug 真心累 。
开发运维更加复杂
绝大多数人选择微服务的主要原因之一就在于 ， 能够在多个不同类型的服务器上运行不同的服务 。
为什么？React 前端的需求完全不同于训练机器学习模型的服务 ， 比如内存、CPU 和正常运行的时间等 。 针对每个服务选择正确的基础设施可以大大降低成本 。 但同时也会带来挑战 。 举个例子 ， 在职业生涯的早期 ， 我曾经造成了大量生产数据丢失 ， 因为在更新完某个服务的代码后 ， 我忘了重启服务 ， 旧代码通过API请求接收数据 ， 然后出错了 ， 未能成功地将这些数据保存到数据库 ， 也没有报错 。 所以 ， 数据永久地丢失了 。
我举这个例子是为了说明与单体应用相比 ， 配置、维护和监控多个微服务需要付出更多的努力 。 此外 ， 拥有多个应用也会导致黑客攻击的途径增加 。