1、微服务 简介

什么是微服务？

微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行在自己的进程中，服务之间相互协调、相互配合，为用户提供最终价值。

服务之间采用轻量级的通信机制相互沟通（一般为基于 HTTP 的 RESTful API）。

每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。

另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。

微服务特性

• 每个微服务可独立运行在自己的进程里；
• 一系列独立运行的微服务共同构建起了整个系统；
• 每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理，用户管理等；
• 微服务之间通过一些轻量级的通信机制进行通信，例如通过 REST API 或者 RPC 的方式进行调用。

技术维度理解微服务

微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底地取耦合，每一个微服务提供单个业务功能的服务，一个服务做一件事，从技术角度看就是一种小二独立的处理过程，类似进程概念，能够自行单独启动或销毁，拥有自己独立的数据库。

例如：

• 发邮件独立的工程
• 发短信独立的工程
• …

单体架构 与 微服务架构

单体架构 和 微服务 的区别：

• 单体架构所有的模块全都耦合在一块，代码量大，维护困难，微服务每个模块就相当于一个单独的项目，代码量明显减少，遇到问题也相对来说比较好解决。
• 单体架构所有的模块都共用一个数据库，存储方式比较单一，微服务每个模块都可以使用不同的存储方式（比如有的用redis，有的用mysql等），数据库也是单个模块对应自己的数据库。
• 单 体架构所有的模块开发所使用的技术一样，微服务每个模块都可以使用不同的开发技术，开发模式更灵活。

单体架构

一个归档包包含了应用所有功能的应用程序，我们通常称之为单体应用。架构单体应用的架构风格，我们称之为单体架构。

单体架构在规模比较小的情况下工作情况良好，但是随着系统规模的扩大，它暴露出来的问题也越来越多。

缺点：

• 复杂性逐渐变高
  比如有的项目有几十万行代码，各个模块之间区别比较模糊，逻辑比较混乱，代码越多复杂性越高，越难解决遇到的问题。

• 技术债务逐渐上升
  公司的人员流动是再正常不过的事情，有的员工在离职之前，疏于代码质量的自我管束，导致留下来很多坑，由于单体项目代码量庞大的惊人，留下的坑很难被发觉，这就给新来的员工带来很大的烦恼，人员流动越大所留下的坑越多，也就是所谓的技术债务越来越多。

• 部署速度逐渐变慢
  这个就很好理解了，单体架构模块非常多，代码量非常庞大，导致部署项目所花费的时间越来越多，曾经有的项目启动就要一二十分钟，这是多么恐怖的事情啊，启动几次项目一天的时间就过去了，留给开发者开发的时间就非常少了。

• 阻碍技术创新
  比如以前的某个项目使用struts2写的，由于各个模块之间有着千丝万缕的联系，代码量大，逻辑不够清楚，如果现在想用spring mvc来重构这个项目将是非常困难的，付出的成本将非常大，所以更多的时候公司不得不硬着头皮继续使用老的struts架构，这就阻碍了技术的创新。

• 无法按需伸缩
  比如说电影模块是CPU密集型的模块，而订单模块是IO密集型的模块，假如我们要提升订单模块的性能，比如加大内存、增加硬盘，但是由于所有的模块都在一个架构下，因此我们在扩展订单模块的性能时不得不考虑其它模块的因素，因为我们不能因为扩展某个模块的性能而损害其它模块的性能，从而无法按需进行伸缩。

既然单体架构存在着以上5点的缺陷，所以我们才需要改进架构，目前架构已从开始的单体架构演变到SOA直至今日的微服务架构。

微服务架构

优点：

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

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

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

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

• 按需伸缩
  我们上面说了单体架构在想扩展某个模块的性能时不得不考虑到其它模块的性能会不会受影响，对于我们微服务来讲，完全不是问题，电影模块通过什么方式来提升性能不必考虑其它模块的情况。

• DevOps
  由于微服务架构下项目是靠多个单独的微服务共同运行的，那么部署微服务便成了问题，因为靠手工区部署的话，会浪费很多时间，这时自动化的部署方式便迫在眉睫了，DevOps便是帮我们自动部署微服务的，从而节约了我们的时间成本。

缺点：

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

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

• 接口调整成本高
  比如，用户微服务是要被订单微服务和电影微服务所调用的，一旦用户微服务的接口发生大的变动，那么所有依赖它的微服务都要做相应的调整，由于微服务可能非常多，那么调整接口所造成的成本将会明显提高。

• 重复劳动
  对于单体架构来讲，如果某段业务被多个模块所共同使用，我们便可以抽象成一个工具类，被所有模块直接调用，但是微服务却无法这样做，因为这个微服务的工具类是不能被其它微服务所直接调用的，从而我们便不得不在每个微服务上都建这么一个工具类，从而导致代码的重复。

微服务的设计原则：

• 单一职责原则
  意思是每个微服务只需要实现自己的业务逻辑就可以了，比如订单管理模块，它只需要处理订单的业务逻辑就可以了，其它的不必考虑。

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

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

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

微服务的开发框架，有以下四个。

• Spring Cloud：http://projects.spring.io/spring-cloud（现在非常流行的微服务架构），比 Dubbo 拆分的更小

• Dubbo：http：//dubbo.io

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

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