身边的人都说微服务好，好在哪？

微服务的优势

大项目可以持续交付

微服务将一个大系统拆分成很多个互相独立的服务，每一个服务都可以由一个团队去完成，并且配备自己的开发、部署，而且可以独立于其他的团队。每一个团队开发的微服务都可以由自己的代码仓库、以及部署流水线等，互不相扰。

在微服务中，一个大项目被拆分成 n 多个小项目，每一个小项目都可以非常方便的进行测试、部署，而不会牵一发而动全身，原本需要全员高度警戒的项目上线，现在分散到不同的团队中去完成。

松哥六月底参加深圳的一个线下技术活动，某在线编程的 CEO 谈到他们公司的发版，说：“我说话的这会儿，我们可能就有新版本在发布。”，这句话令我印象深刻。传统的单体应用，没人敢这么搞，微服务时代，这一切才变得可能。

易于维护

这个不必多说，相信大家都理解。

一个传统的单体应用，如果你新接手，一时半会还不一定能理出一个头绪，而如果是微服务，由于比较小巧玲珑，一个微服务只负责一件事情，很容易理出头绪，然后上手开发。

并且相对于单体应用，微服务规模都比较小，无论你用 Eclipse 还是 IDEA，项目启动、测试速度都比较快。

服务可以独立扩展

独立扩展，可以让我们充分使用硬件资源。

传统的单体应用，所有的功能模块都写在一起，有的模块是 CPU 运算密集型的，有的模块则是对内存需求更大的，这些模块的代码写在一起，部署的时候，我们只能选择 CPU 运算更强，内存更大的机器，如果采用了了微服务架构，不同的系统独立部署，压力大的时候，可以独立进行集群化部署，这些操作都不会影响到已经运行的其他微服务，非常灵活。

更强的容错性

由于每一个微服务都是独立运行的，处理得当，我们在微服务架构中可以实现更好的故障隔离。当一个微服务发生问题时，例如内存泄漏，不会影响到其他的微服务。

可以灵活的采用最新技术

传统的单体应用一个非常大的弊端就是技术栈升级非常麻烦，这也是为什么你经常会见到用 10 年前的技术栈做的项目，现在还需要继续开发维护。不是他们不愿意升级，而是升级实在是太麻烦了，伤筋动骨。

而在微服务架构中，每一个服务都是独立运行的，单个微服务的技术升级则非常容易。你可以随意去尝试你喜欢的最新技术。因为试错成本很低，因此大家可以尽情的玩耍。

微服务的弊端

事物都有两面性，微服务也有一些挑战，这些挑战性问题如果处理不好，你使用微服务可能反而适得其反。那么都有哪些问题呢？

• 服务的拆分

个人觉得，这是最大的挑战，我了解到一些公司做微服务，但是服务拆分的乱七八糟。这样到后期越搞越乱，越搞越麻烦，你可能会觉得微服务真坑爹，后悔当初信了松哥的说微服务好的鬼话。

• 分布式系统带来的挑战

记得以前在网上看到过一个段子：

没用分布式架构之前，你只有一个问题：并发性能不足。用了分布式架构，多出了一堆问题：数据如何同步、主键如何产生、如何熔断、分布式事务如何处理......。

这个段子形象的说明了分布式系统带来的挑战。

• 多个研发团队的协调管理

传统的单体应用开发，一个团队管理好就行了，现在不同的团队开发不同的微服务，要协调多个团队共同配合，才能做好微服务开发，这对项目管理提出了挑战。

好了，本文就先说这么多，大伙可以留言说说你的项目有没有使用微服务，出于什么样的考虑而使用了目前的架构呢？