近日,GitHub 前 CTO Jason Warner 在推特上表示,“我确信过去十年中,最大的架构错误之一就是全面使用微服务。”

注意这里的全面使用,意味着在不合适的场景使用了微服务。

哪些场景不适合,可以从人数、人员能力、组织结构、业务形态等多方面来评估。

从人数看

  • 公司小,如果是一家 5-50 人的公司,只需坚持使用单体。
    原因:小公司应该投入力量做业务,而不是解决微服务的可视性、治理等一些的事情,业务的变化应该更敏捷,而不是每次变一堆微服务。
  • 一个服务不应该只有1个人来维护,服务的代码质量,工作的交接都会有问题。
  • 一个人平均不应该维护超过2个服务,否则他就没有足够的精力做深、做透这部分,很容易这部分处于失控的边缘。
  • 架构设计需要考虑时间维度,最初时很多人一起做某个项目,满足上面的要求,但是随着服务进入维护期,人员减少了,不能出现维护不过来情况。

从人员能力看

  • 微服务化后,需要很多基础设施的能力建设,否则研发效率、故障时定位时间、持续集成等都会成为问题,这样就会引入更很多工具。这些工具是否有人会用,有人可以维护?有人可以按照企业特色场景定制开发?

  • 微服务间需要大量的交互,他们之间的边界API设计是否合理?是否能随着业务不断迭代仍然稳定和高效?这需要高水平的架构师进行宏观把控,企业是否具备这样的人才?

  • 全体RD的研发素质如何?编码规范、单元测试、研发技能、人员培养机制这些都需要比较高的水平才可用好微服务。

从组织和业务看

当涉及几十个微服务或更大规模时,企业遇到通常并非技术问题,而是组织上的挑战。

  • CEO是否愿意在微服务上持续投入?是否愿意持续的治理微服务化后的架构腐化? 一般微服务化后当年,表现都还不错,但是持续2年后,团队就没法更快地交付,会陷入“爆炸性”的复杂性中。几十个微服务的治理难度要远大于几个宏服务的治理。

  • 过多的服务常常会导致所有权和边界问题,业务边界稳定么?一年变一次组织,微服务是否要重构?

总结

微服务并不是适用所有场景,Uber有个可借鉴的拆分原则:

服务于一项业务功能,由 5-10 个工程师负责维护

企业应该根据自己的情况(当前和对未来的预判)来选择,而不是一味追随潮流,给自己造成不能很好支持业务的架构腐化。

参考:

原文地址:http://www.cnblogs.com/ghj1976/p/wei-fu-wu-jia-gou-zui-jin-de-tiao-zhan-fen-xi.html

1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长! 2. 分享目的仅供大家学习和交流,请务用于商业用途! 3. 如果你也有好源码或者教程,可以到用户中心发布,分享有积分奖励和额外收入! 4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解! 5. 如有链接无法下载、失效或广告,请联系管理员处理! 6. 本站资源售价只是赞助,收取费用仅维持本站的日常运营所需! 7. 如遇到加密压缩包,默认解压密码为"gltf",如遇到无法解压的请联系管理员! 8. 因为资源和程序源码均为可复制品,所以不支持任何理由的退款兑现,请斟酌后支付下载 声明:如果标题没有注明"已测试"或者"测试可用"等字样的资源源码均未经过站长测试.特别注意没有标注的源码不保证任何可用性