前言：
本次培训为我们讲解了企业级架构的发展史、搭建微服务架构的意义以及搭建微服务架构实操，并从理论学习过度到从公司目前系统架构的现状出发，如何在公司架构环境下做微服务架构转型。此次微服务的培训，给我们最大的收获就是帮助我们把有关微服务的碎片化知识整理成了一张知识网。并帮助我们从开发、运维、DBA等不同角色分析微服务场景下的工作内容。为后面企业级微服务的搭建提供了普众化的认知。使得我们每个人都能清晰的知道在微服务架构下，自己角色的分工，同时对整体架构层面也有了自己的认知和考量。
为了便于复盘，现在整理下学习笔记。
-------------------------------------------------------------------------------
课程目录：
1、互联网时代信息化系统（非功能性需求）
2、x86服务集群
3、微服务系统架构
4、docker容器+k8s集群
微服务弹性资源管理平台构建（三）
5、微服务体系架构的构建（实操）
微服务弹性资源管理平台构建（四）
6、微服务数据结构体系架构的构建
7、数据中台的构建
微服务的由来：
计算机商用发展之初，所有商用系统的构建都需要依赖于IOE（IBM的服务器、Oracle的数据库、EMC的存储设备），高昂的成本就成了应用系统在中小型企业普及的瓶颈，而对于银行、保险、证券等大型企业，这本部分费用也占去了企业很大一笔开销。依赖于IOE的应用系统，硬件成本动辄几千万，甚至上亿，那时候的系统搭建基本架构如下：
1、为了达到应用的高可用，防止单点故障，同时部署两台应用系统，通过ip tab 创建续ip，以HA架构解决两台服务的主备切换。
2、使用EMC的作为两台数据库共用的存储设备，保证数据的一致性。
-----------------------题外---------------------
解决单机故障的方式有两种：
1、HA架构->Shadow master 也称续ip https://www.cnblogs.com/kevin-yuan/p/6726822.html
2、多活，https://baijiahao.baidu.com/s?id=1668554353987778263&wfr=spider&for=pc
----------------------------------------------------
随着谷歌等非金融、保险、证券类公司对系统的需求，去IOE走向了历史的舞台。谷歌尝试用个人电脑做主机，搭建起了谷歌最初的搜索引擎，亚马逊通过x86搭建的服务集群扛过了黑色星期五，国内阿里巴巴也从08年开始提出在主要业务上去IOE。这一系列操作，使得x86集群被越来越多的企业所接受。
以共享单车为例，产品应用的业务场景需要A（车辆定位模块）、B（订单生产模块）、C（CRM用户管理模块）、D（查找附件单车模块）、E（支付模块）、F（解、关锁模块）五个应用模块。
起初，为了资源的合理分配，会根据不同模块的访问需求，为不同模块分配不同数量的服务做应用部署，架构如下：
随着业务的发展，我们需要不断地对业务系统进行扩容,那么这样的架构就会给运维人员带来不能完成的工作任务，因为每台服务器上面部署的应用不尽相同，那么台服务器维护的方式就会各有不同，如果将服务器从40台扩容到2000台，那么这样的架构对运维人员来说就是灭顶之灾。为了解决运维难的问题，出现了负载均衡+全部署（full devlploment）。
x86集群架构下负载均衡+全部署+前后端分离+redis做session共享的架构图如下左：
这样的架构设计，虽然通过全部署降低了运维工作的复杂性，使得扩容可以实现，但是因为每台服务器上面部署的应用都是一样的，依然做不到功能的复用和资源的弹性分配，同时，全部署还有一个极其不能容忍的弊端----> 系统耦合性太大！！！全部署的应用无法做到快速开发、快速迭代、快速发版，每个模块的改造、发版、升级都会造成全流程的回归测试，这是单机部署的弊端。懒人创造世界，总会有人厌倦了这样笨重的系统架构，寻找释放双手的完美方案，那么，微服务就出现了。
小结：
互联网系统非功能性需求：
1、高性能 2、高并发 3、高可用 4、横向扩容
||
大规模算力集群（几万台服务器的运维与治理，超出了人力运维的能力范畴）
|| 衍生出新的需求：
5、高效运维 6、快速发布（3天一版） 7、弹性计算资源调度
微服务是什么?
微服务架构=业务微服务分解+java/go语言开发+功能进程+对外接口REST+docker容器化部署+k8s应用部署集群。
微服务剖析：
1、微服务是一种企业级的平台架构，并不是应用层级或系统层级的架构，简单来说，一个企业，常理来说应该只用一个微服务平台。
2、微服务的核心价值是做业务的服用
3、微服务的分解：依据业务分解（具体问题具体分析，但一定要做到企业级分解标准的统一）
分解方法:（需求可以分为一级需求--模块级的和二级需求--功能级的）
1)原子服务：可以最大化的实现服务复用
2）一级服务：封装（组合）原子服务 --> 组成一个功能模块，对外开发，提供业务支持。
3）领域服务：业务实体 （CRUD）
4）自主定义服务：为了减少网络io的调用，将原本的多个原子服务做成一个服务，为了做企业级服务的治理，这种服务的创建需要走流程审核并备案。
4、微服务的运行：独立运行（其实本质就是一个进程）
5、微服务通信：REST、RPC、Netty（长连接）
6、微服务的部署：docker+k8s集群
7、微服务语言：Java、go、python、c++
介绍完微服务的概念，我们来介绍下微服务平台运维部署层面必不可少的两个技术：docker+k8s。