微服务简介

微服务是什么？

一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据上下文，选择合适的语言、工具对其进行构建。

简单来说，将一个系统，拆分为多个模块，每一个模块作为一个独立的小系统进行整合起来。

• 各模块（小系统）之间采用特定的通讯方式（http、rpc等）相互沟通（业务串联）。
• 各系统不一定使用相同的编程语言开发。

1.微服务的优势与缺点

1.1优点

• 易于开发和维护

  微服务中单个模块就相当于一个独立项目或者一个小系统，开发时我们就可以只需关心这个模块的逻辑，代码量和逻辑复杂度都会降低，从而易于开发和维护。

  单体架构的系统开发时多人开发定会存在代码冲突问题，微服务开发则能减少这种情况。

• 启动较快

  这个是对于整体系统来比较的，微服务单个模块系统的启动速度比单体架构系统启动速度明显是要快很多。这点能减少很大的开发成本。

• 单点修改容易部署

  在日常开发中发现了问题或者修改了业务，单体架构需要整体停机维护发布，而微服务架构只需要将对应的服务进行重新发布即可。

• 技术栈不受限

  例如一个微服务架构系统中存有多个微服务，每个微服务都可以使用不同的编程语言开发。如果某个功能、模块使用java语言开发效率高就可以切换java，如果go语言效率高则可以使用go语言。

• 按需伸缩

  传统单体架构在想扩展某个模块的性能时不得不考虑到其它模块的性能会不会受影响，对于我们微服务来讲，完全不是问题，各个模块只需管理好自己的就行。

  还有某个模块访问量会比其他模块的访问量大时、可以指定扩大此模块系统的启动数量。

1.2缺点

• 运维要求较高

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

• 分布式的复杂性

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

• 接口调整成本高

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

• 重复劳动

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

微服务的特性

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

以上是我对微服务的理解，如有错误点请给予建议知道。诸君安康共勉之~