微服务概念入门及发展历程
一、为何学习微服务、何为架构、何为系统
1.为什么要学习微服务
1.1、提升架构设计
1.2、扩展知识面。
2.什么是架构
2.1、什么是架构：架构指的是系统的结构。这里有两个概念，系统和结构
2.2、什么是系统：系统是一组关联的个体（一组个体的关联集合），它可以完成个体不能完成的任务。
现实理解为：软件公司比作系统，测试、开发、产品为个体，这些个体组合成一家公司，完成个体不能完成的任务。电商系统也类似。
系统的现实理解如上图。
2.3、什么是结构：指的是系统内部各个组件之间的关联方式。系统内的各个组件，能够进行通信。
因此，架构就是系统的结构。它有三个特点
a.由各个具体的组件组成
b.各个组件能相互通信
c.可以合作完成一个共同的任务
2.4架构分类：架构又可以分为 部署架构 和 逻辑架构（功能架构）。
二、什么是微服务，什么是微服务架构
1.什么是微服务
只提供一项功能的服务。
2.什么是业务领域
公司有多少业务，就有多少领域。一个领域，就是一个业务。比如 电商业务领域、OA业务领域 等。
3.微服务和业务领域的关系
微服务是围绕某个业务领域展开的。把电商业务比较一个业务领域，技术部、产品部等就是围绕电商业务领域展开的微服务。在电商项目领域，由支付、商品、订单等微服务组成。如下图所示：
4.微服务的特征
4.1、单一职责原则。
4.2、升级简单，扩展轻松：由于微服务只提供一项功能，职责单一，代码也少，因此代码也相对比较少，因此升级简单，易扩展。
4.3、独立性强：出问题了，微服务之间互相不影响。一个微服务出问题了，不影响其他微服务正常工作。
5.什么是微服务架构
如何将拆分出来的各个微服务进行管理形成的结构，就是微服务架构。包括各个微服务的组件以及他们之间的通信方式。完成微服务架构，需要一系列的技术栈。微服务架构理解示例，如下图所示：
从架构图中可以看出，整个微服务架构的核心是微服务层。
6.微服务架构的目的
6.1.解决性能问题（并发量）
6.2.解决数据量问题
6.3.解决业务量问题
6.4.解决团队量问题
三、微服务架构的衍化过程
接下来，以为团队管理系统为例，介绍微服务架构衍化过程。团队管理系统有 团队模块 和 团队成员，团队模块有技术、测试、销售等。每个具体的团队模块都有相应的成员。系统每一个模块，代表一个业务，业务会发展，变得越来越多、越来越复杂。系统功能也会随之越来越多，越来越复杂。
(一)、单体架构
单体架构的缺点是 处理并发量有限，不能承载高并发量的访问。每个物理主机的吞吐量都是有限的，当并发量起来后，承载应用程序的服务器性能会下降，甚至可能宕机。要解决高并发问题，应用程序开始做集群。
(二)、单数据库多应用架构
为了解决并发量的问题，开始对应用程序做集群，并使用nginx做负载均衡（或者采用其他网关做负载均衡）。
单数据库多应用架构，在应用程序上解决了并发量问题。随着并发量的增加，数据量也会骤增。数据量问题出现，数据库的性能下降，影响整个系统的性能。
(三)、主从数据库读写分离
为了解决数据量问题，于是对数据库做主从分离架构。
这种架构解决了并发量问题，也一定程度上解决了数据量问题。当并发量持续增加，数据库性能依然无法进一步提升。因为 应用程序跟数据都的交互，是通过网络IO进行的，而每个数据库的读写性能也是有限的。为了解决这个问题，则需要加上缓存。
(四)、主从数据库读写分离+缓存架构
随着并发量提升到一定量级，这种架构依然会导致整体性能下降。任何系统，对外的能力超过了一定的阈值（并发能力的阈值），系统性能都会急剧下降。因此可以看出，并发量贯穿着每种架构的过程。为了解决并发量持续加大的问题，出现了 消息队列架构。
(五)、消息队列架构(异步架构)
可是即使是消息队列架构模式，也只能解决并发量和数据量问题。团队量 和 业务量 并没有得到解决。在业务发展过程中，系统功能会越来越多且越来越复杂，业务量就会增长。由于业务量增多，需要维护系统的团队工作量也会增多。因为所有的集群，都是同一个系统，一个团队共同维护一个业务庞大的系统，会有维护冲突的问题。会导致 ：
1.升级缓慢，bug不断。
2.模块之间相互影响。
除此之外，当某个模块（如 团队模块）的并发量非常高，占用的线程资源和其他资源过多，而一台物理服务器的线程资源是有限的，必然会影响其他模块的响应性能。为了解决 业务量 和 团队量，出现了面向服务（SOA）架构
(六)、面向服务(SOA)架构
但是这种架构有一个非常繁重的企业服务总线 ESB。ESB协议繁多，维护复杂。服务层 粒度不够明确。三个缺陷：
1.ESB协议繁多，维护复杂。
2.服务拆分粒度不明确，服务没有大小和具体的规范，不利于团队管理
3.数据都存储再同一个数据库，导致各个模块数据之间相互影响。其中一个模块数据量大，会影响其他模块数据的读写性能。
为了解决并发量、数据量、业务量、团队量的问题。微服务架构顺势而生。
(七)、微服务架构
微服务架构，是目前业务架构的最高设计。每一个服务，都是独立的数据库。单个服务出问题了，不影响其他服务。服务与服务之间，是轻耦合的状态。它的协议简单，要嘛是http的，要嘛是restful的，或者其他协议。但是协议只有一个，扩展简单。
微服务架构可以解决：
1.解决并发量问题
2.解决数据量问题
3.解决业务量问题
4.解决团队量问题
微服务架构的缺陷：
1.服务增多，数据库增多，复杂性增高。一个系统，根据粒度拆分成服务，应用和数据库的规模都会增加。
2.系统不稳定因素增大，维护量增大。每个服务之间通信，服务与工具层之间通信，都需要通过网络进行，而网络是非常不可靠的。因此增加了系统不稳定性。
微服务架构，没有足够的团队资质，是非常难实施的。