微服务的简单介绍

微服务的简单介绍

微服务概述

微服务（或微服务架构）是一种云原生架构方法，其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。这些服务

• 通常有自己的堆栈，包括数据库和数据模型；
• 通过REST API，事件流和消息代理的组合相互通信；
• 它们是按业务能力组织的，分隔服务的线通常称为有界上下文。

尽管有关微服务的许多讨论都围绕体系结构定义和特征展开，但它们的价值可以通过相当简单的业务和组织收益更普遍地理解：

• 可以更轻松地更新代码。
• 团队可以为不同的组件使用不同的堆栈。
• 组件可以彼此独立地进行缩放，从而减少了因必须缩放整个应用程序而产生的浪费和成本，因为单个功能可能面临过多的负载。

简而言之：微服务是近几年流行的一种**架构思想**

这里我们引用Martin Fowler关于微服务的一些话：

原文链接：https://martinfowler.com/articles/microservices.html
汉化链接：https://www.cnblogs.com/liuning8023/p/4493156.html

• “微服务（Microservices）”——只不过在满大街充斥的软件架构中的一新名词而已。尽管我们非常鄙视这样的东西，但是这玩意所描述的软件风格，越来越引起我们的注意。在过去几年里，我们发现越来越多的项目开始使用这种风格，以至于我们身边的同事在构建企业级应用时，把它理所当然的认为这是一种默认开发形式。然而，很不幸，微服务风格是什么，应该怎么开发，关于这样的理论描述却很难找到。
• 简而言之，微服务架构风格，就像是把一个单独的应用程序开发为一套小服务，每个小服务运行在自己的进程中，并使用轻量级机制通信（通常是 HTTP API）。这些服务围绕业务能力来构建，并通过完全自动化部署机制来独立部署。这些服务使用不同的编程语言书写，以及不同数据存储技术，并保持最低限度的集中式管理。

简单理解：

• 微服务化就是将传统的一站式应用，根据不同的业务拆分成一个一个的服务，彻底的去耦合，每个微服务提供单一的业务功能，一个服务做一件事。

微服务与微服务架构

微服务
强调的是服务的大小，它关注的是某个一点，是具体解决某一个问题/提供落地对应服务的一个服务应用，狭义的看，可以看做IDEA的一个个微服务工程，或者Moudel

IDEA工具里面使用Maven开发一个个独立的小moudle，它具体是使用springboot开发的一个小模块，专业的事情交给专业的模块来做，一个模块就做一件事。
强调的是一个个个体，每个个体完成一个具体的任务或者功能。

微服务架构
一种新的架构形式，Martin Fowler， 2014提出

微服务架构是一种架构模式，它提倡将单体应用程序划分成一组小的服务，服务之间互相协调，相互配合，为用户提供最终价值。每个服务运行在其独立的进程，服务与服务间采用轻量级的通信机制互相协作，每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境中。另外，应尽量避免统一的，集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言，工具对其进行构建。

微服务优势与缺点

1.特性

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

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

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

微服务之间通过一些轻量级的通信机制进行通信，例如通过REST API或者RPC的方式进行调用。
2. 特点

• 易于开发和维护

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

• 启动较快

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

• 局部修改容易部署

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

• 技术栈不受限

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

• 按需伸缩

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

3. 缺点

• 运维要求较高

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

• 分布式的复杂性

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

• 接口调整成本高

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

• 重复劳动

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

如果你有兴趣学习微服务其他知识：
springcloud（一）-- 环境搭建及多模块使用RestTemplate实现api调用