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