前言:
在介绍微服务时，首先得先理解什么是微服务，顾名思义，微服务得从两个方面去理解，什么是"微"、什么是"服务"，
微，狭义来讲就是体积小、著名的"2 pizza 团队"很好的诠释了这一解释（2 pizza 团队最早是亚马逊 CEO Bezos提出来的，意思是说单个服务的设计，所有参与人从设计、开发、测试、运维所有人加起来 只需要2个披萨就够了 ）。 而所谓服务，一定要区别于系统，服务一个或者一组相对较小且独立的功能单元，是用户可以感知最小功能集。
微服务这么火，多少人多少公司都想试试水。
了解到很多小伙伴在找 Java 开发工作时，如果这个公司用的微服务架构，就觉得很牛逼，进去了很有前景，如果没用微服务，甚者还用的是以前的 SSH ，就会觉得没前景，不想去。由此可见微服务在大家心中的分量。
不过话说回来，并非每一个项目都是适合用微服务架构，也并非每一个公司都需要微服务架构。有个朋友在某网红茶公司做微服务开发，新项目架构师强行上马微服务，结果项目上线后，一个小小的变更都要修改许多服务才能解决，没办法，架构师只能卷铺盖走人了，项目又变回了单体应用。
我觉得这样的例子不是个案，项目要不要上马微服务，还是要看项目和公司的具体情况，不盲目，不跟风。
今天来和大家聊一聊微服务到底有哪些好处，又有哪些弊端。
大项目可以持续交付
微服务将一个大系统拆分成很多个互相独立的服务，每一个服务都可以由一个团队去完成，并且配备自己的开发、部署，而且可以独立于其他的团队。每一个团队开发的微服务都可以由自己的代码仓库、以及部署流水线等，互不相扰。
在微服务中，一个大项目被拆分成 n 多个小项目，每一个小项目都可以非常方便的进行测试、部署，而不会牵一发而动全身，原本需要全员高度警戒的项目上线，现在分散到不同的团队中去完成。
我六月底参加深圳的一个线下技术活动，某在线编程的 CEO 谈到他们公司的发版，说：“我说话的这会儿，我们可能就有新版本在发布。”，这句话令我印象深刻。传统的单体应用，没人敢这么搞，微服务时代，这一切才变得可能。
易于维护
这个不必多说，相信大家都理解。
一个传统的单体应用，如果你新接手，一时半会还不一定能理出一个头绪，而如果是微服务，由于比较小巧玲珑，一个微服务只负责一件事情，很容易理出头绪，然后上手开发。
并且相对于单体应用，微服务规模都比较小，无论你用 Eclipse 还是 IDEA，项目启动、测试速度都比较快。
服务可以独立扩展
独立扩展，可以让我们充分使用硬件资源。
传统的单体应用，所有的功能模块都写在一起，有的模块是 CPU 运算密集型的，有的模块则是对内存需求更大的，这些模块的代码写在一起，部署的时候，我们只能选择 CPU 运算更强，内存更大的机器，如果采用了了微服务架构，不同的系统独立部署，压力大的时候，可以独立进行集群化部署，这些操作都不会影响到已经运行的其他微服务，非常灵活。
更强的容错性
由于每一个微服务都是独立运行的，处理得当，我们在微服务架构中可以实现更好的故障隔离。当一个微服务发生问题时，例如内存泄漏，不会影响到其他的微服务。
可以灵活的采用最新技术
传统的单体应用一个非常大的弊端就是技术栈升级非常麻烦，这也是为什么你经常会见到用 10 年前的技术栈做的项目，现在还需要继续开发维护。不是他们不愿意升级，而是升级实在是太麻烦了，伤筋动骨。
而在微服务架构中，每一个服务都是独立运行的，单个微服务的技术升级则非常容易。你可以随意去尝试你喜欢的最新技术。因为试错成本很低，因此大家可以尽情的玩耍。
事物都有两面性，微服务也有一些挑战，这些挑战性问题如果处理不好，你使用微服务可能反而适得其反。那么都有哪些问题呢？
服务的拆分
个人觉得，这是最大的挑战，我了解到一些公司做微服务，但是服务拆分的乱七八糟。这样到后期越搞越乱，越搞越麻烦，你可能会觉得微服务真坑爹，后悔当初信了说微服务好的鬼话。
分布式系统带来的挑战
记得以前在网上看到过一个段子：
没用分布式架构之前，你只有一个问题：并发性能不足。用了分布式架构，多出了一堆问题：数据如何同步、主键如何产生、如何熔断、分布式事务如何处理......。
这个段子形象的说明了分布式系统带来的挑战。
多个研发团队的协调管理
传统的单体应用开发，一个团队管理好就行了，现在不同的团队开发不同的微服务，要协调多个团队共同配合，才能做好微服务开发，这对项目管理提出了挑战。
好了，本文就先说这么多，大伙可以留言说说你的项目有没有使用微服务，出于什么样的考虑而使用了目前的架构呢？
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
