真实案例

1、在多次项目交流中，会经常被问为什么没有使用微服务，很是不解。

其实，那就是个内部系统，用户少、业务简单、数据量小，怎么看也不复杂。

2、领导希望上微服务，专门找了些架构师。

在领导的安排下，架构师们选取了两个新项目进行试点，搞了一年多，勉强上线。

上线后，新项目问题不断。老的项目，也就不再改造了。

Jason Warner的建议

即便是大公司、大团队，想上微服务，也不一定吃得消。

GitHub 前 CTO Jason Warner 也在推特上表示：

I’m convinced that one of the biggest architectural mistakes of the past decade was going full microservice.

（我确信过去十年中，最大的架构错误之一就是全面使用微服务。）

从他的表达可以看出，他不是反对使用微服务，而是不建议全面使用。

不分场景地使用微服务，确实没必要。

Warner给出的建议是：

apps > services > microservices

（单体>应用程序>服务>微服务）

这个建议是很中肯的，也符合现实情况。

现实中，技术都要配合业务的节奏。

系统，就不可避免地，按阶段生长。

系统一开始不复杂，需要快速上线，最适合单体应用。

有了三五个系统，需要交互。做好功能规划，按功能细化接口设计，做对接。

系统之间可拆可合，不怕业务变动，不怕组织架构调整，这样的架构一般能扛很久。

业务进一步发展，几个系统之间交互变得复杂了，就需要提高维护效率。

可以抽离一些公共服务，比如统一的身份验证服务等。

剥离出公共服务，业务系统就轻了，可以专注于业务。

架构也合理，各团队理解起来也不复杂。

现实中的系统，随着时间的推移，几乎都是混合的。

架构修修补补，代码看起来像屎山。

其实是一波波程序员智慧的结晶，不宜轻言废立！