Microservice-微服务-概述
1.概念
狭义：
微（micro）：小；
服务（service）：服务不同于系统，服务是指服务于一个或者服务于一组相对较小且独立的功能单元，是用户可以感知的最小功能集。
广义：
微服务是一种分布式系统解决方案，推动细粒度服务的使用，这些服务协同工作。
2.微服务架构
微服务架构风格是将单个应用程序作为一组小型服务开发的方法，每个服务程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。这些服务是围绕业务功能构建的。可以通过全自动部署机器独立部署。这些服务器可以用不同的编程语言编写，使用不同的数据存储技术，并尽量不用集中式方式进行管理。
3.微服务与微服务架构
- 微服务架构是将复杂的系统使用组件化的方式进行拆分，并使用轻量级通讯方式进行整合的一种设计方法。
- 微服务是通过微服务架构设计方法拆分出来的一个独立的组件化的小应用。
- 微服务架构定义的精髓：分而治之，合而用之。
将复杂的系统进行拆分的方法，就是【分而治之】。
分而治之：可以让复杂的事情变的简单。
用轻量级通讯等方式进行整合的设计，就是【合而用之】。
合而用之：可以让微小的力量变强大。
4.微服务架构与单体式/整体式架构的对比
1.单体式/整体式架构
单体式/整体式架构遵循传统的MVC逻辑分层，并不是物理上的分层。也就是说，对不同层的代码而言，经过编译、打包和部署后，所有的代码最终还是运行在同一个进程中。而这，就是所谓的单体式/整体式架构。
三层架构（MVC）的具体内容如下：
表示层（view）： 用户使用应用程序时，看到的、听见的、输入的或者交互的部分。
业务逻辑层（controller）： 根据用户输入的信息，进行逻辑计算或者业务处理的部分。
数据访问层（model）： 关注有效地操作原始数据的部分，如将数据存储到存储介质（如数据库、文件系统）及从存储介质中读取数据等。
单体架构在规模比较小的情况下工作情况良好，但是随着系统规模的扩大，它暴露出来的问题也越来越多：
1.复杂度逐渐变高
比如有的项目有几十万行代码，各个模块之间区别比较模糊，逻辑比较混乱，代码越多复杂性越高，越难解决遇到的问题。
2.技术债务逐渐上升
公司的人员流动是再正常不过的事情，有的员工在离职之前，疏于代码质量的自我管束，导致留下来很多坑，由于单体项目代码量庞大的惊人，留下的坑很难被发觉，这就给新来的员工带来很大的烦恼，人员流动越大所留下的坑越多，也就是所谓的技术债务越来越多。
3.维护成本大
当应用程序的功能越来越多、团队越来越大时，沟通成本、管理成本显著增加。当出现 bug 时，可能引起 bug 的原因组合越来越多，导致分析、定位和修复的成本增加；并且在对全局功能缺乏深度理解的情况下，容易在修复 bug 时引入新的 bug。
4.持续交付周期长
构建和部署时间会随着功能的增多而增加，任何细微的修改都会触发部署流水线。新人培养周期长：新成员了解背景、熟悉业务和配置环境的时间越来越长。
5.技术选型成本高
单体式架构倾向于采用统一的技术平台或方案来解决所有问题，如果后续想引入新的技术或框架，成本和风险都很大。
6.可扩展性差
随着功能的增加，垂直扩展的成本将会越来越大；而对于水平扩展而言，因为所有代码都运行在同一个进程，没办法做到针对应用程序的部分功能做独立的扩展。
2.微服务架构
1.微服务架构的特点
1.单一职责
微服务架构中的每个服务，都是具有业务逻辑的，符合高内聚、低耦合原则以及单一职责原则的单元，不同的服务通过“管道”的方式灵活组合，从而构建出庞大的系统。
2. 轻量级通信
服务之间通过轻量级的通信机制实现互通互联，而所谓的轻量级，通常指语言无关、平台无关的交互方式。
对于轻量级通信的格式而言，常用的XML 和 JSON是语言无关、平台无关的；对于通信的协议而言，通常基于 HTTP，能让服务间的通信变得标准化、无状态化。REST（Representational State Transfer）是实现服务间互相协作的轻量级通信机制之一。使用轻量级通信机制，可以让团队选择更适合的语言、工具或者平台来开发服务本身。
3.独立性
每个服务在应用交付过程中，独立地开发、测试和部署。
在单体式架构中所有功能都在同一个代码库，功能的开发不具有独立性；当不同小组完成多个功能后，需要经过集成和回归测试，测试过程也不具有独立性；当测试完成后，应用被构建成一个包，如果某个功能存在 bug，将导致整个部署失败或者回滚。
在微服务架构中，每个服务都是独立的业务单元，与其他服务高度解耦，只需要改变当前服务本身，就可以完成独立的开发、测试和部署。
4.进程隔离
单块架构中，整个系统运行在同一个进程中，当应用进行部署时，必须停掉当前正在运行的应用，部署完成后再重启进程，无法做到独立部署。
有时候会将重复的代码抽取出来封装成组件，在单块架构中，组件通常的形态叫做共享库（如 jar 包或者 DLL），但是当程序运行时，所有组件最终也会被加载到同一进程中运行。
在微服务架构中，应用程序由多个服务组成，每个服务都是高度自治的独立业务实体，可以运行在独立的进程中，不同的服务能非常容易地部署到不同的主机上。
2.微服务架构的缺点
1. 运维要求较高
对于单体式架构来讲，只需要维护好一个项目就可以了，但是对于微服务架构来讲，由于项目是由多个微服务构成的，每个模块出现问题都会造成整个项目运行出现异常，想要知道是哪个模块造成的问题往往是不容易的，因为无法一步一步通过debug的方式来跟踪，这就对运维人员提出了很高的要求。
2.分布式的复杂性
对于单体式架构来讲，可以不使用分布式，但是对于微服务架构来说，分布式几乎是必会用的技术，由于分布式本身的复杂性，导致微服务架构也变得复杂起来。
3.接口调整成本高
比如，用户微服务是要被订单微服务和电影微服务所调用的，一旦用户微服务的接口发生大的变动，那么所有依赖它的微服务都要做相应的调整，由于微服务可能非常多，那么调整接口所造成的成本将会明显提高。
4.重复工作代码冗余
对于单体式架构来讲，如果某段业务被多个模块所共同使用，可以抽象成一个工具类，被所有模块直接调用，但是微服务却无法这样做，因为这个微服务的工具类是不能被其它微服务所直接调用的，从而不得不在每个微服务上都建这么一个工具类，从而导致代码的重复。
3.对比
| 对比点 | 船体单体式/整体式架构 | 微服务架构 |
|---|---|---|
| 新功能开发 | 开发周期长 | 容易开发和实现 |
| 部署 | 容易部署，不经常发布 | 部署复杂，经常进行发布 |
| 隔离性 | 故障影响范围大 | 故障影响范围小 |
| 架构设计 | 初期技术选型难度大 | 设计逻辑难度大 |
| 系统性能 | 相对时间快，吞吐量小 | 相对时间慢，吞吐量大 |
| 系统运维 | 运维难度简单 | 运维难度复杂 |
| 新人上手 | 应用逻辑学习曲线大 | 架构逻辑学习曲线大 |
| 技术 | 技术单一而且封闭 | 技术多样且容易开发 |
| 测试和差错 | 简单 | 复杂（每个服务都要进行单独测试，还需要进行集群测试） |
| 系统扩展性 | 扩展性差 | 扩展性好 |
| 系统管理 | 重点在于开发成本 | 重点在于服务治理和调度 |
4.微服务架构优势
1.开发简单
微服务架构将复杂系统进行拆分之后，让每个微服务应用都开放变得非常简单，没有太多的累赘。
2.快速响应需求变化
一般的需求变化都来自于局部功能的改变，这种变化将落实到每个微服务上，每个微服务的功能相对来说都非常简单，更改起来非常容易，所以微服务非常适合敏捷开发方法，能够快速的影响业务的需求变化。
3.随时随地更新
一方面，微服务的部署和更新并不会影响全局系统的正常运行；另一方面，使用多实例的部署方法，可以做到一个服务的重启和更新在不易察觉的情况下进行。所以每个服务任何时候都可以进行更新部署。
4.系统更加稳定可靠
微服务运行在一个高可用的分布式环境之中，有配套的监控和调度管理机制，并且还可以提供自由伸缩的管理，充分保障了系统的稳定可靠性。
