微服务（第二十六天）

微服务

微服务（Micro services）是架构演变的产物，相对于单体架构，它用了抽象的思维，将一个系统抽象化，拆成几个小的独立的服务，再把独立的服务串起来

微服务特性：

每个微服务都运行在自己的空间里；一系列独立运行的微服务共同构建起了整个系统；
每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如网络管理，用户管理等；
微服务之间通过一些轻量级的通信机制进行通信，例如REST API或者RPC的方式进行调用
面向服务的。将自己的业务能力封装并对外提供服务
微服务带来的挑战：
运维要求高，分布式的复杂性增加，接口调整成本高，升级需要各个组件统一配套

微服务的设计原则：

单一职责，服务自治，轻量级通信，接口明确

系统架构模型：

单体架构模型：
在这里插入图片描述

集群模型：

在这里插入图片描述

分布式模型：

在这里插入图片描述

微服务架构模型：

在这里插入图片描述

高可用弹性伸缩云架构

在这里插入图片描述

既然是系统演变，那么相对于单体架构，它的优缺点如何？

单体架构：
在这里插入图片描述
客户端:浏览器（B/S），可能是（C/S),安卓，IOS，以及可对接协议终端设备

单体应用的后台功能是所有的服务进程跑在一台服务器上，所有的消息入口是有本机进行收发，而后台业务处理也是由本机进行处理。

缺点：

开发的问题：所有人开发代码都在一个工程，编译构建可能要一两个小时。
性能问题：CPU IO Fd的利用率很低，所有业务混织在一起。
业务稳定性问题：所有的模块仅仅耦合在一起，一旦进程dump ，整个系统就挂掉，也就是业务容错能力差。
并发业务量问题：适合嵌入式用户量较小的情况。
扩展的问题：很难代码重构以及业扩展。
回归测试周期长，修复一个bug可能都需要对所有基础业务进行回归测试。

优点：运维成本低，部署简单，基本单机可以搞定。

微服务架构：

在这里插入图片描述

把一个庞大的系统拆成几个小的独立的服务，再把独立的服务串起来。

优点：

有专门的运维负责安装部署，可自定义进行部署。
扩展系统的瓶颈（cpu，内存，io、并发）可以解决
微服务架构的缺点：
微服务开发的复杂度简化，但部署和服务跟服务之间的复杂度会提高
服务与服务之间采用远程调用的方式进行交互，这样它们之间没有干扰和冲突，边界非常清晰，例如我们需要给用户信息加字段，只需要修改用户服务，其它的服务并无感知。单体架构就要麻烦很多，即使是变更一个小功能点，也需要发布整个系统
微服务不是集中式管理，不同服务的技术团队，可以基于自身技术特点或者服务的业务特性选择完全不同的技术栈。
弊：
服务众多，技术多样，这样带来的挑战就是增加了研发人员的理解和学习成本。一个单体架构系统，技术栈是统一的，而且系统架构简单，就只有单体应用的几个节点，研发人员理解起来非常容易。
-微服务架构是一种分布式系统架构，对于任何分布式系统而言，数据的最终一致性，强一致性变为弱一致性。要么使用复杂的设计实现最终一致性，但是开发的成本也会因此提升
微服务对于运维在部署、监控、扩展、管理等方面都提出了更高的挑战。
测试复杂性
对于单体应用，直接测试整个系统功能就可以了；微服务后，各个系统分散在各个团队，需要多个团队联调做集成测试。
微服务组件：