1.微服务的简介
假设一个场景：网上电影购票系统，涉及的模块有电影模块、订单模块、用户模块。
在没有微服务之前，我们的做法可能是，一个项目，存放所有的模块信息，当前，这种做法也没有问题，可以实现功能，随着我们的业务系统越来越大，代码量，还有用户人群越来越大，这样脓肿的项目，就会存在各种各样的问题，代码维护成本，硬件成本，不好维护等等。这样微服务就应运而生。
我们常说微服务，那什么是微服务？
所谓的微服务是SOA架构下的最终产物，该架构的设计目标是为了肢解业务，使得服务能够独立运行。微服务设计原则：1、各司其职 2、服务高可用和可扩展性。
微服务架构是从SOA架构演变而来的，比SOA架构粒度更加精细，让专业的人，做专业的事，目的是为了提高效率，每个服务于服务之间互不影响，每个服务必须独立部署(独立数据库,独立redis)，微服务架构更加体现轻量级，采用restful风格提供api，也就是使用http协议+json格式进行传输，更加轻巧，更加适合于互联网公司进行敏捷开发，快速迭代产品。而SOA架构采用的是SOAP协议,也就是http+xml(占用空间大)
2.微服务的优点
2.1易于开发和维护
一个微服务只关注一个特定业务功能，所以代码逻辑清晰，代码量少，这样就易于维护，而整个应用是有 多个微服务构建而成。例如：上面的购票系统，用户模块就需要辅助用户的业务逻辑，而不用管电影，订单的业务。
2.2 单个服务启动快
单个服务，代码量较少，所以启动较快。本人之前就遇到过，启动一个项目服务花了5分钟左右，这还是小型系统，如果是大型系统，启动服务半个小时，也是正常，而一般的外部系统，时时刻刻可能有人在用，所以，一般的部署时间点，都是在凌晨左右，如果中间空缺半个小时左右不能用，我想你的电话，要被客户和公司的人打爆把。
2.3 单一修改易于部署
单一应用，只要修改，就得重新部署整个项目，而微服务就不一样，只需要重新发布修改的那个服务就行，一般这个服务，也不止一个，案例：例如游戏的版本1.4 1.5，实际上上线1.5的过程中，1.4版本还是可以正常使用的，这就是因为，该服务不止一份，也就是说，部署不影响系统的客观使用。
2.4 技术不受限制
在微服务中，我们可以根据team掌握的技术，合理的选择技术
3.微服务的缺点
3.1.运维要求较高
单一应用，只需要打一个包直接部署就行，而微服务，可能是几十个或者上百个服务构成一个应用系统。所以对运维要求较高。
3.2 分布式复杂性
使用微服务构建的是分布式系统，可能存在系统容错，网络延迟，分布式事务等问题
3.3 接口调整成本高
微服务之间都是通过接口通讯的，如果需要某一个微服务的接口，可能该服务对应的一系列接口都要更改。
3.4 重复劳动
服务之间可能有重复的代码，而这部分代码，没有达到需要独立成一个服务的程度，所以，会有重复代码。
原文链接：https://blog.csdn.net/qq_16855077/article/details/90605665