一、概念

微服务：一个单体应用分成多个小的功能单位。

1、优点：

（1）单体架构的代码过于集中臃肿，微服务化之后代码复杂性减少，逻辑结构更加清晰（结构本身的优点）

（2）单体服务的部署速度较慢，微服务化之后部署速度更快（对技术人员而言）

（3）单体的灵活性差，资源很难按需伸缩。微服务的灵活性更强，更加适合云计算架构

总结：微服务的目的就是有效的拆分应用，实现敏捷开发和部署。

2、特性：

（1）每个微服务可独立运行在自己的进程里；

（2）一系列独立运行的微服务共同构建起了整个系统

（3）每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理，用户管理等

（4）微服务之间通过一些轻量级的通信机制进行通信，例如通过REST API或者RPC的方式进行调用

3、特点：

优点：

（1）易于开发

由于微服务单个模块就相当于一个项目，开发这个模块我们就只需关心这个模块的逻辑即可，代理量和逻辑复杂度都会降低，从而易于开发和维护。

（2）启动较快

这里相对单个微服务来讲的，相比于启动单体脚骨的整个项目，启动某个模块的服务速度明显是要快很多的。

（3）局部修改容易部署

在开发中发现一个问题，如果是单体架构的话，我们就需要重新发布并启动整个项目，非常耗时，但是微服务则不同，哪个模块出现了bug我们只需要解决那个模块的bug就可以了，解决完bug之后，我们只需要重启这个模块的服务即可，部署相对简单，不必重启整个项目从而大大节约时间。

（4）技术相对不受限

比如订单微服务和电影微服务原来都是用java写的，现在我们想把电影微服务改写成node Js技术，这是完全可以的，而且由于所关注的只是电影的逻辑而已，因此技术更换的成本就会少很多。

（5）按需伸缩

单体架构再想扩展某个模块的性能时不得不考虑其他模块的性能会不会受影响，对于我们微服务来讲，完全不是问题，电影模块通过什么方式来提升性能不必考虑其他模块的情况。

缺点：

（1）运维要求较高

对于单体架构来讲，我们只需要维护好这一个项目就可以了，但是对于微服务架构来讲，由于项目是多个微服务架构构成的，每个模块出现问题都会造成整个项目运行出现异常，想要知道是哪个模块造成的问题往往是不容易的，因为我们无法一步一步通过debug的方式来跟踪，这就对运维人员提出了很高的要求。

二、架构

1、微服务，关键其实不仅仅是微服务本身，而是系统要提供一套基础的架构，这种架构使得微服务可以独立的部署、运行、升级。不仅如此，这个系统架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体，这个所谓的统一整体表现出来的是统一风格的界面，统一的权限管理，统一的安全策略，统一的上线过程，统一的日志和审计方法，统一的调度方式，统一的访问入口等等。

2、微服务开发框架：

目前微服务的开发框架，最常用的有以下四个：

Spring Cloud、Dubbo、Dropwizard、consul、etcd&etc

（1）spring cloud是现在非常流行的微服务架构，提供微服务工具包，为开发者提供了再分布式系统的配置管理、服务发现、断路器、微代理、控制总线等开发工具包。

（2）dropwizard关注单个微服务的开发

三、应用：什么项目适合微服务

        微服务可以按照业务功能本身的独立性来划分，如果系统提供的业务是非常底层的，如：操作系统内核、存储系统、网络系统、数据库系统等等，这类系统都偏底层，功能和功能之间有着紧密的配合关系，如果强制拆分为较小的服务单元，会让集成工作量急剧上升，并且这种人为的切割无法带来业务上的真正隔离，所以无法做到独立部署和运行，也就不适合做成微服务了。

       能不能做成微服务，取决于四个要素：

（1）小：微服务体积小

（2）独：能够独立的部署和运行

（3）轻：使用轻量级的通信机制和架构

（4）松：微服务之间是松耦合的。