为什么使用微服务
架构演变如上图所示，从单体架构，到垂直架构，到SOA面向服务架构，再到微服务架构。每一次的成功演变，都会出现新的需求，面临新的问题，为了适应新的需求，必然会出现的事物。我们先来看看传统IT架构面临的一些问题：
在单体架构中，所有功能集中在一个项目中，所有功能都要达成war包部署到服务器，这样全部的功能都集中在一个项目中完成,对于大型项目来说,开发难度高,不容易开发及扩展和维护。在垂直架构中，以单体架构为单位进行系统的划分,划分成一个个系统，项目与项目之间存在数据冗余,耦合度高，虽然进行了分成，但是还是全部的功能都集中在一个项目中完成,对于大型项目来说,开发难度高,不容易开发及扩展和维护。在SOA服务架构中，进行了功能的抽取，已服务为中心来管理项目，利用ESB来管理各个系统之间的调用关系，但是ESB没有统一的标准，种类很多，不利于维护。并且随着云计算及互联网公司大量开源轻量级技术的不停涌现并日益成熟，这一切催生了新的架构风格-微服务架构。
微服务架构通用特性
微服务的提出者是马丁.福勒，是敏捷开发的创始人之一，被开发者们尊为“教父”。虽然他没有直接给微服务下一个精准的定义，但是给出了微服务通用特征描述：
1、根据业务模块划分服务种类：微服务架构中将组件定义为可被独立替换和升级的软件单元，在应用架构设计中通过将整体应用切分成可独立部署及升级并且互相隔离的微服务方式进行组件化设计。
2、产品而非项目模式(Productsnot Projects)：传统的应用模式是一个团队以项目模式开发完整的应用，开发完成后就交付给运维团队负责维护；微服务架构则倡导一个团队应该如开发产品般负责一个“微服务”完整的生命周期，倡导“谁开发，谁运营”的开发运维一体化方法。
3、“去中心化”治理(DecentralizedGovernance)：整体式应用往往倾向于采用单一技术平台，微服务架构则鼓励使用合适的工具完成各自的任务，每个微服务可以考虑选用最佳工具完成(如不同的编程语言)。微服务的技术标准倾向于寻找其他开发者已成功验证解决类似问题的技术。
4、“去中心化”数据管理(DecentralizedData Management)：微服务架构倡导采用多样性持久化(PolyglotPersistence)的方法，让每个微服务管理其自有数据库，并允许不同微服务采用不同的数据持久化技术。
5、基础设施自动化(InfrastructureAutomation)：云化及自动化部署等技术极大地降低了微服务构建、部署和运维的难度，通过应用持续集成和持续交付等方法有助于达到加速推出市场的目的。
6、故障处理设计(Designfor failure)：微服务架构所带来的一个后果是必须考虑每个服务的失败容错机制。因此，微服务非常重视建立架构及业务相关指标的实时监控和日志机制。
7、智能端点与管道扁平化(Smartendpoints and dumb pipes)：微服务架构主张将组件间通讯的相关业务逻辑/智能放在组件端点侧而非放在通讯组件中，通讯机制或组件应该尽量简单及松耦合。RESTful HTTP协议和仅提供消息路由功能的轻量级异步机制是微服务架构中最常用的通讯机制。
什么是微服务
以上是微服务的的一些通用特性，由以上特性，我们可以将微服务理解为是以专注于单一责任的小型功能模块为基础，通过通讯机制相互通信，采用云化及自动化部署的方式完成复杂业务系统搭建及部署的一种设计思想。
微服务的本质
1、微服务，关键其实不仅仅是微服务本身，而是系统要提供一套基础的架构，这种架构使得微服务可以独立的部署、运行、升级，不仅如此，这个系统架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。这种所谓的“统一的整体”表现出来的是统一风格的界面，统一的权限管理，统一的安全策略，统一的上线过程，统一的日志和审计方法，统一的调度方式，统一的访问入口等等。
2、微服务的目的是有效的拆分应用，实现敏捷开发和部署 。
3、微服务提倡的理念团队间应该是 inter-operate, not integrate 。inter-operate是定义好系统的边界和接口，在一个团队内全栈，让团队自治，原因就是因为如果团队按照这样的方式组建，将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合能变弱，跨系统的沟通成本也就能降低。
微服务特点
1、 易于开发和维护：开发这个模块我们就只需关心这个模块的逻辑即可，代码量和逻辑复杂度都会降低，从而易于开发和维护。
2、 局部修改容易部署：哪个模块出现了bug我们只需要解决那个模块的bug就可以了，解决完bug之后，我们只需要重启这个模块的服务即可，部署相对简单，不必重启整个项目从而大大节约时间。
3、 技术栈不受限：比如订单微服务和电影微服务原来都是用java写的，现在我们想把电影微服务改成nodeJs技术，这是完全可以的，而且由于所关注的只是电影的逻辑而已，因此技术更换的成本也就会少很多。
微服务优点
1、一系列微小的服务共同组成
2、 跑在自己的进程里
3、 每个服务为独立的业务开发
4、独立部署
5、分布式的管理
结语
软件发展的不同时期、阶段，对技术的理解、选择和应用都有着不一样的诉求。架构的选型，永远只有“合适与不合适”，永远没有“哪个更好”的说法。我们今天来谈论微服务，并不是因为它更牛，而是经过谨慎分析，认为微服务的思想更符合我们的目标。但微服务也有他自己的不足之处，比如运维要求较高；接口调用成本较高，一个接口的改动，可能会引起多个服务的变动；每一次架构的选择，我们都应该根据自身条件以及项目需要来做出合适的选择。