75% 新项目都可以“无脑”选择单体架构( 三 ) _单体架构

但如果我们还没有做好使用微服务架构的万全准备，甚至才刚刚踏出探索的第一步，那人员与服务间的对应关系恐怕没有那么清晰。换句话说，大家在开发新功能时，往往不免要触及到由其他人编写的服务。

假定我们是一支负责开发登录服务的团队，服务本体由 Java 编写。另一支团队则开发会话服务，至少在项目启动之初是如此。每个人都对产品万分期待、充满动力，并努力用新鲜元素满满的创新方案解决现实问题。于是乎，会话服务是用 Node.js 编写的，因为最近刚刚面世了一套全新 JS 框架，大家都赞不绝口、说它能把生产力提高好几倍之类的。

文章插图

接下来，MVP 已经初步成型，产品开始在生产环境下运行。向个月后，会话服务（Node.js 服务）的构建者开始过渡到其他项目，甚至离职去了其他公司。接下来这段时间就成了空窗期，大家不再为会话服务开发任何相关功能。

突然之间，产品负责人跳出来说“大家好，我们需要上线新功能，用来扩展平台上的会话服务。”但这时候原本的会话服务创建者已经离职，另一支接手团队却没有任何会话服务或者 Node.js 开发经验。

于是大家傻眼了，根本不知道自己能不能接下这样一份重担。

下面，咱们再来聊聊 DevOps 。我倒不是想刻意针对 DevOps，但如今各类组织都在积极组建独立于工程团队的专职 DevOps 部门，这真有必要吗？DevOps 并不是什么万金油，DevOps 工程师也不可能了解每种语言和技术细节。所以就算顶着这个光芒四射的头衔，他们也很可能搞不定服务运营工作。

另外，很多产品负责人或者公司老板也不够负责，他们压根不重视由不同编程语言带来的种种隐患。比如说继续沿用 Java 开发某项服务只需要 2 周时间，但为了跟其他服务保持统一，我们最好花 6 周时间用另一种语言来编写，他们会同意吗？估计够呛，毕竟短期来看时间就是生命。但如果真这么随性，一旦人员离职、产生代码交接需求，后面的麻烦完全可以预见。

不止于此，异构系统还会带来其他跨越性的新难题。比如如何实现标准化……

日志记录
安全保护
状态监控
国际化
错误处理

我们得在不同的语言和技术栈上一遍遍重复这些标准化调整，这工作可不轻松，而且要求各个团队付出大量精力。我记得我们就曾在一个已经开发 5 个月的项目中使用到 80 多项微服务，当时大家打算标准化 API 错误处理，保证生成一致的 HTTP 代码。5 个小队最初的预估周期就长达 107 天，而且这还不属于异构系统——所有代码都是用 Java + Spring Boot 编写的。可以想象一下，如果代码涉及三、四种不同语言和技术栈，工作量会膨胀到什么地步。

我当然不反对使用多种语言/技术栈，但这事最好要有明确的理由，比如切实需要某些语言/技术栈中的功能特性。我也会在低延迟负载中使用 Go 或者 Node.js，并倾向于使用 Java 开发逻辑更复杂、但对性能要求不高的任务——但一定要有理有据。

这里再分享一点在异构架构方面的经验。我接触过的一套架构涉及五种语言，分别是 Java、Scala、Node.js、Erlang 等。团队当然就得随时维持这五种代码，可以想象会有多困难。更要命的是，里面还涉及不同的 Java 版本、不同的开发框架等。事实证明，很多语言的引入根本没有必要，开发者这么干只是因为他们好奇、想要实验一下。

我当然相信产品的成功源自人的成功，而人的成功源自对创新的探索。但我也觉得创新这事不能泛滥，我们在制定决策时必须小心谨慎、保证充分理解“创新”背后的含义。从个人角度来看，“我就是想试试”不能叫理由，这种随心所欲的风格只会给项目留下无数暗伤、拖累后续发展。

文章插图

团队扩张团队的扩张可以说是使用微服务架构的最佳论据。设想一下，一支 10 人小队在一个单体式代码库上工作，效果很好、复杂性始终不高。

但如果扩大团队规模，让 100 个人同时处理一个单体式代码库，结果会如何？代码库相同、工作方式相同，一切都不做变动。大家会把代码推送至同一个 git repo，使用相同的类、相同的测试、处理 10 项不同功能。