一、微服务架构概述

1、为什么会出现微服务

1.1、单体应用的问题

    单体应用——一个war包包含了所有功能的应用程序。

    问题：随着需求增加，一个单体项目会变得越来越臃肿，可维护性降低。

• 复杂性高：模块多、依赖不清，混乱堆砌
• 技术债务：技术人员变更，老代码难以维护修改
• 部署频率低：每次简单修改就要整个臃肿项目重新部署，所以一般少部署
• 可靠性差：一个小bug，可能导致整个项目的崩溃（如：死循环，OOM）

1.2、单体应用架构上的问题

    扩展能力受限——只能作为整体去扩展，无法灵活伸缩。如：有些模块计算密集，需要强劲CPU，有些IO密集需要大内存，揉在一个war包里部署，硬件上不好选择

    阻碍技术创新——引入新框架必须改整个项目，几乎不可能

由此，微服务就应运而生！

2、什么是微服务

2.1、简单定义

    （把之前的）单一应用开发成一组小型服务，服务间采用轻量级通信（如Http），这一组服务可以集中管理，每个服务可以用不同的语言技术来实现。

2.2、微服务的特性

• 一个微服务运行在自己独立的进程中
• 一个微服务实现某一特定功能（如订单管理）
• 一个微服务可与同组其他服务用不同的语言技术

    如图：

 

2.3、微服务的优点与挑战

2.3.1、优点

    一个微服务就是一个功能业务，业务清晰、代码少、启动快。技术上可以按需选用不同的语言、技术框架。如果某个微服务遇到瓶颈，可以按需增加配置

2.3.2、面临的挑战

•     运维成本高——一组微服务要集中管理
•     分布式固有复杂性——网络延迟、分布式事物、系统容错等
•     接口调整成本高——微服务通信靠接口，用到该接口的地方都要修改
•     重复劳动——不同微服务里可能出现同样的（不适合抽取，但）重复性的代码

2.4、微服务设计原则

•     单一职责原则——只关注功能中单独、有界的一部分
•     服务自制——独立业务能力、依赖和运行环境，高度解耦、独立运行
•     轻量级通信机制——体量轻、跨语言、跨平台，如REST、AMQP
•     微服务粒度——随业务场景定义

2.5、微服务架构的实现

2.5.1、技术选型

    框架——可选用spring cloud作为微服务开发框架，“开箱即用”提供了微服务的完整解决方案。（dubbo也可以但是主要针对Java项目）

    运行平台——不绑定运行平台，推荐使用Docker做部署

2.6、微服务架构图