1、为什么要使用微服务？
要说为什么要使用微服务，我们要先说下传统的企业架构模式-垂直架构/单块架构模式，简单点说：我们一般将系统分为三层架构，但是这是逻辑上的三层，而非物理上的三层，这就意味着经过编码后，我们需要将这三层的代码打包部署，最终还是运行在同一台机器的同一个进程中。即单块架构模式就是功能集中，代码数据集中，一个发布包、部署运行在同一个进程中的应用程序，重点是同一个进程。
这种架构存在自己的优势也有弊端，优势是：易于开发，易于测试，易于部署，易于水平伸缩。
弊端：维护成本高，修改一处代码就需要重新部署；持续交付周期长；信任培养周期长；技术选型成本高，可扩展性差。
正是因为有了这些弊端，后期出现了SOA(面向服务的架构)，但是SOA是粗粒度的服务模式，后面又出现了MSA，所以微服务是SOA的一个子集，是SOA的一个细化，是细粒度的服务。
2、什么是微服务？
这个没有什么明确的定义，可以这么理解：微服务是一种架构模式，将单一的应用程序划分成多个小组服务，这些小组服务互相协调，互相配合，最终完成整个项目。这些小的服务可以根据上下文选用自己适合的语言、工具来进行实现，实现了高度自治。个人认为：类似于中国有56个民族，这56个民族构成了中国整个大国，但是每个民族有自己的语言自己的风俗习惯，实现了民族自治。
3、微服务有哪些优势？
对比传统的单一架构模式，我们可以看到微服务的不同，分布式的服务模式，每个模块独立自治。所以这出现了它的优势：
（1）服务作为组件。这个组件可以这样理解：比如汽车由不同的零部件构成，当某个零部件出问题的时候，我们只要修理这个零部件即可，每个零部件都是可以独立升级独立替换的。
所以可以认为每个小服务是一个组件。
（2）围绕业务组织团队：根据不同的业务来组织团队，实现敏捷开发。
（3）关注产品而非项目
（4）技术的多样性，由于服务的自治性，每个业务可以采用不同的技术实现。
（5）业务数据独立：比如一个ＣＲＭ系统，对于数据较多，更新又比较频繁的我们可以使用文档型的数据库ｍｏｎｇｏＤＢ，对于用户访问系统时产生的会话信息，我们使用ｒｅｄｉｓ存储，而对于结构性强，数据比较多，但变化不大的我们可以采用关系型数据库。
（６）基础实施自动化：这里主要使用云来快速构建系统资源，ＤｅｖＯｐｓ的运维。（这个暂时不太清楚）
（７）演进式架构
4、微服务有哪些缺点？
每个事物都有两面性，有优点也有缺点：
（１）分布式系统的复杂度：
性能方面：由于采用了分布式，服务间的通信需要考虑网络延迟以及带宽的影响。
可靠性：有可能出现单点故障
数据的一致性：分布式的事务管理需要跨多个节点，因此这个数据一致性是一个问题。
（２）运维成本
配置、部署、监控和警告、日志收集的成本升高。
（３）部署自动化：微服务的每个服务单元很多，由于系统迭代很快，我们需要多次更新，而现在还需要人工部署审查这些，所以部署的自动化就面临着挑战。
（４）服务间的依赖测试：测试每个服务间的正常通信量加大，测试面临挑战。
总结：微服务强调的是一种独立开发、独立测试、独立部署、独立运行的高度自治的架构模式，也是一种更灵活、更开发、更松散的演进式架构。
ps：本文转载，原链接：https://www.cnblogs.com/fengli9998/p/6680828.html