微服务思想

一、什么是微服务

1.1、概念

微服务：把一个大型的单个应用程序和服务，拆分为数个甚至数十个的互联服务，每一个服务都是一个迷你应用。

1.2、本质

用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。

微服务这个概念是 2012 年出现的，作为加快 Web 和移动应用程序开发 进程的一种方法，2014 年开始受到各方的关注，同年为微服务的元年。

// 注释：它只是一个开发方式的理念，类似于面向对象这种开发理念，并没有限定要用什么具体的技术来实现
// 即 java 能做微服务，node 能做微服务，Python 也能做...

1.3、微服务和分布式的区别

• 分布式：属于微服务的一种，不同模块 部署在 不同服务器上 ，为了解决高并发和负载的问题。

• 微服务：架构设计概念，可能 不同模块 都部署在 同一台服务器上 ，但是各个模块完全隔离，为了让每个模块都能（单一职责、独立部署）

二、为什么有优势

2.1、传统开发模式

与微服务对应于的 传统开发模式 开发方式称为：单体式开发

特点：既所有的功能打包在 一个 WAR 包 里，部署在一个Tomcat里，这里包含了一个项目完整的 DAO，Service，UI 等所有逻辑。

小型单体项目（OA办公系统，银行系统）：

功能简单，模块之间关系清晰，用户量较少，访问并发量不高。这时候单体模式能很 良好的运行。

// 注释： 这种功能简单的类型，不适用微服务模式进行改造

庞大的单体项目（互联网电商项目）：

功能非常复杂，几百万条代码，高并发，复杂的业务模块，掉入单体地狱。

• 整个项目臃肿庞大，改旧 BUG 容易引出新的 BUG

• 启动时间很长，可能要 12+ 分钟，调试和部署会很困难

• 整个项目都部署在一个服务器上，计算量庞大，需要这个服务器足够好，成本上升

• 单个模块出现错误（内存泄漏），会导致整个项目都崩溃

• 采用的具体技术框架不可以中途变更，比如项目用 java SSM 开发，运营两年后没办法换成 Node.js，除非重构整个项目

• 所有功能都写在一个项目里，功能繁杂，新来的开发人员很难理解旧代码

2.2、微服务开发模式

把一个大型的单个应用程序和服务，拆分为数个甚至数十个的互联服务，每一个服务都是一个迷你应用。

每一个服务会给其他服务提供 REST API，但是各个微服务之间的 直接调用 是一个不小的网络负担，并且很麻烦，一般都会在 N 个服务添加一个代理或者叫 API Gateway （网关），一般用 Nginx 实现 他的作用包括：

• 提供统一服务入口，让微服务对前台透明
• 聚合后台的服务，节省流量，提升性能
• 提供安全，过滤，流控等 API 管理功能

每一个实例（模块）通常是一个 云虚拟机 或者 Docker容器 ，每个服务都有明确定义边界的方式。

特点与优势：

• 每个服务都是独立的，开发人员可以分工，每个开发者专注于自己的模块，易于维护
• 每个服务都可以独立进行技术选型，比如 注册登录模块用 java SSM 开发，订单模块用 Node.js 开发，产品服务模块用 Python 开发，最后分别部署在3个 Docker 容器中，良好运行。这样就能保证在旧系统上开发新模块时，能随时采用最新合适的技术
• 服务都较小，当需要重写单个服务时（比如将 java SSH 改为 java SSM），工作量小
• 每个服务能独立部署，一经测试即可部署，模块越小启动越快

三、怎么做

微服务大多采用 Docker 为容器，一台服务器可以有 N 个容器。每个容器里可以安装不同的镜像，如 Tomcat 镜像、java 镜像、Nginx 镜像，Node.js镜像，组成一个独立的运行环境，类似于虚拟机。
cker 为容器，一台服务器可以有 N 个容器。每个容器里可以安装不同的镜像，如 Tomcat 镜像、java 镜像、Nginx 镜像，Node.js镜像，组成一个独立的运行环境，类似于虚拟机。