微服务的必要性

有一次在与客户交流过程中，客户提出“我们的系统遇到了很大的瓶颈，运行极慢，我们该怎么办？微服务之后能否解决慢的问题？”

相信大家也遇到过类似的问题，系统往往最初刚上线的时候运行的很好，甚至三五年都很好，但是随着时间的推移，业务与数据的增长使得我们的系统不再如初上线时那么流畅，变得非常臃肿（不灵活，庞大，效率低下）。我们该怎么办？

一、“协作”，通过扩充团队力量，实现快速响应，此方法如同蚂蚁搬家，通过团队协作实现效率提升。这也好比我们应用架构的集群化方案，单台扛不住，我们就多台的意思。但这并没有解决根本性问题。同时该方案对团队成员的能力要求非常高，要求团队成员能迅速融入，并快速上手。往往对于一个臃肿的大单体应用来说，团队成员又无法快速融入，快速上手。从而形成了矛盾体，所以我们一般会进行第二种方案。

二、“分解（分而治之）”，对当一个应用已经无法通过增加团队成员来提升效率的情况。我们势必会进行分解，将一个大应用拆成小应用。通过业务拆分，实现应用灵活可扩展，微小易控制，DevOps敏捷提升。这也就是我们常说的微服务架构。

微服务架构能否解决慢的问题？我们先不说微服务架构，我们先来谈慢的问题，应用为什么慢，到底是哪里慢呢？恰恰这也是微服务的一个核心要素——聚焦核心问题。对我们不应当讨论微服务的必要性，而应当讨论应用为什么慢？

对于应用变慢的总结：

1、硬件过时

我们知道硬件更新换代的速度快的惊人（诺基亚、摩托罗拉、柯达数码等等都是硬件厂商鲜明例证），计算