微服务架构是什么？微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。

微服务设计原则

单一职责原则

每个微服务只需要实现自己的业务逻辑即可。比如订单管理模块，它只需要处理订单的业务逻辑就可以，其它的不必考虑。

图中左边是单体架构的集群，右边是微服务集群

传统的单体架构是以整个系统为单位进行部署，而微服务则是以每一个独立组件为单位进行部署。

服务自治原则

每个微服务从开发、测试、运维等都是相互独立，互不干扰，包括存储的数据库也是，自己就有一套完整的流程，我们完全可以把它当成一个项目来对待，不必依赖于其它模块。

微服务的设计思想对团队的划分有着一定的影响，使得团队组织架构的划分更倾向于垂直架构，比如用户业务是一个团队来负责，支付业务是一个团队来负责。

轻量级通信原则

首先是通信的语言非常的轻量，第二，该通信方式需要跨语言、跨平台，之所以要跨平台、跨语言就是为了让每个微服务都有足够的独立性，可以不受技术的钳制。

接口明确原则

由于微服务之间可能存在着调用关系，为了尽量避免以后由于某个微服务的接口变化而导致其它微服务都做调整，在设计之初就要考虑到所有情况，让接口尽量做得更通用，更灵活，从而尽量避免其它模块也做调整。

微服务特点

易于开发和维护

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

启动较快

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

局部修改易于部署

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

如上图，每个微服务都有自己的业务层和数据库，这样做，改变其中一个微服务，不会影响其他的服务。

技术栈不受限

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

按需伸缩

根据实际运营需求，快速水平扩展服务部署。

运维要求较高

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

分布式的复杂性

对于单体架构来讲，我们可以不使用分布式，但是对于微服务架构来说，分布式几乎是必会用的技术，由于分布式本身的复杂性，导致微服务架构也变得复杂起来。

微服务开发框架

常用微服务的开发框架：

1.Spring Cloud：http://projects.spring.io/spring-cloud（现在非常流行的微服务架构）

2.Dubbo：http：//dubbo.io

3.Dropwizard：http://www.dropwizard.io（关注单个微服务的开发）

4.Consul、etcd&etc.（微服务的模块）

Sprint cloud和Sprint boot区别

Spring Boot:

旨在简化创建产品级的Spring应用和服务，简化了配置文件，使用嵌入式web服务器，含有诸多开箱即用微服务功能，可以和spring cloud联合部署。

Spring Cloud：

微服务工具包，为开发者提供了在分布式系统的配置管理、服务发现、断路器、智能路由、微代理、控制总线等开发工具包。

电商云平台展示

电商云平台基于多年的业务沉淀，以“大中台小前台的”思想，以微服务的架构，将各业务线中共享的功能沉淀到中台服务，加强中台赋能业务前台的能力。