有一次在与客户交流过程中，客户提出“我们的系统遇到了很大的瓶颈，运行极慢，我们该怎么办？微服务之后能否解决慢的问题？”
相信大家也遇到过类似的问题，系统往往最初刚上线的时候运行的很好，甚至三五年都很好，但是随着时间的推移，业务与数据的增长使得我们的系统不再如初上线时那么流畅，变得非常臃肿（不灵活，庞大，效率低下）。我们该怎么办？
一、“协作”，通过扩充团队力量，实现快速响应，此方法如同蚂蚁搬家，通过团队协作实现效率提升。这也好比我们应用架构的集群化方案，单台扛不住，我们就多台的意思。但这并没有解决根本性问题。同时该方案对团队成员的能力要求非常高，要求团队成员能迅速融入，并快速上手。往往对于一个臃肿的大单体应用来说，团队成员又无法快速融入，快速上手。从而形成了矛盾体，所以我们一般会进行第二种方案。
二、“分解（分而治之）”，对当一个应用已经无法通过增加团队成员来提升效率的情况。我们势必会进行分解，将一个大应用拆成小应用。通过业务拆分，实现应用灵活可扩展，微小易控制，DevOps敏捷提升。这也就是我们常说的微服务架构。
微服务架构能否解决慢的问题？我们先不说微服务架构，我们先来谈慢的问题，应用为什么慢，到底是哪里慢呢？恰恰这也是微服务的一个核心要素——聚焦核心问题。对我们不应当讨论微服务的必要性，而应当讨论应用为什么慢？
对于应用变慢的总结：
1、硬件过时
我们知道硬件更新换代的速度快的惊人（诺基亚、摩托罗拉、柯达数码等等都是硬件厂商鲜明例证），计算机的更新换代就更不在话下。我们不得不在硬件方面加大投入来提升我们的应用性能。而且我们需要根据应用的特性来进行弹性的伸缩。例如CPU型应用、内存型应用、存储类应用对硬件的要求是不一样的。这也就是我们常说的分布式架构，或者说分布式应用，通过分布式解决应用特性弹性伸缩问题。还有就是集群，上面讲到通过增加团队增加人的集群，下面这相当于通过增加机器增加服务器的集群。
2、网络耗时
网络耗时这也是个极大的痛点。从2G到5G时代主要解决的也是网络问题，通过优化网络链路及网络环境减少网络耗时。互联网企业一般采用专线、CDN等技术提升网络性能。同时结合应用特性、优化应用传输数据，减少数据传输量级，从而提升网络性能。
3、前端性能体验
前端相比较早些年，真是质的变化，量的飞跃。以React、Vue为主流的前端框架让应用真正的实现了前后端的分离。通过采用这种前沿技术提升性能体验，是我们最常用的方法。我想补充的是业务优化，前端显示什么，不显示什么，什么时候显示，在哪显示，如何显示等等都将带来不同的性能体验。往往这个优化空间还是蛮大的，我们需要予以关注。
4、后端应用性能
后端性能常常通过优化API接口（如入参、出参优化，逻辑优化，SQL优化等）、梳理服务依赖（避免环形和双向依赖）、聚焦核心问题（通过聚焦主业务、降级辅业务保证核心业务性能）等来提升后端性能。
5、存储瓶颈
存储一般存储在物理机或虚拟机上，当然在如今非常盛行的容器化时代，也可能是容器环境。往往第一步我们需要对存储环境进行优化。当然这需要结合选用的存储中间件来进行差异化调整。其次就是存储中间件本身的优化（如数据库参数、索引优化、语句优化；分库分表方案；读写分离等），Redis高速缓存、TiDB分布式数据库、ES、Hadoop、FastDFS、RabbitMQ等，具体中间件具体调优（本文略）。
6、全链路监控缺失
我们回归的主题，应用慢，到底慢在哪？客户一脸茫然，为什么呢？因为他不清楚，是真不清楚，为什么会出现这种情况，其实就是全链路监控的缺少，我们常说不怕出问题，怕的是出了问题无法快速定位，快速解决。全链路监控实现了应用的可监控性，可测试性，让我们不再茫然。
总结：
微服务之必要性，通过微服务架构模式我们可以将不确定的问题拆分为足够小，足够清晰的应用，帮助我们梳理问题。微服务应用有助于我们更好的实现分布式，实现根据不同业务特性弹性伸缩。同时微服务由于其微小，使得我们更容易控制，也更容易进行DevOps敏捷迭代，快速交付。同时结合微服务治理平台可以对服务进行全链路监控，实现业务高可用。微服务不能直接解决慢的问题，但是微服务可以帮你一步步拆解慢的问题，最终解决应用问题。当然微服务很美好，但是微服务同样会带来新的问题，这里略，所以最后总结没有完美的架构，只有适合的架构。架构也是一个演进迭代的过程。
