一、服务的演变之路
1.1）单体架构（all in one）
单体项目缺点：
某些服务比如库存更加依赖IO，可以偏向于数仓磁盘进行针对性提升，某些服务比如会员服务针对于会员的下单习惯进行算法推荐更依赖CPU计算，可以偏向于高CPU/高内存进行针对性提升。而单体只能又是大磁盘、又是高CPU高内存。
在于服务选型方面比如订单服务需要将Hibernetes转型为mybatis需要排除对于其它服务的影响，而且很容易牵一发动全身很多框架之间不兼容的隐性Bug出现
单体项目优点：
比微服务省略很多维护成本，部署简单一个jar包不关心启动顺序，不需要RPC调用都是本地效率高，像初创公司也不需要很多研发人员。
架构也就是M（Model）V（View）C（Controller），Model层对应infrastructure负责逻辑计算，View对应Service层负责计算出来结果展现，Contorller对应Web负责计算出来结果承装从而向外部展现
1.2）集群级垂直化
随着竞品越来越多服务量增大，服务进行横向拆分不同系统打包成不同war包，有时间的将数据库也进行拆分，内部通讯可以使用RPC外部可以使用Http，原先10个请求只能打到一个Tomcat服务器，现在两个Tomcat平摊各自只需要承担5个请求，再往下平摊到不同的war包上又分摊了压力
以系统为粒度会出现不同系统对于差不多的功能都需要自己去反复实现
1.3）SOA
随着服务量越来越大SOA的承载力全部压在ESB企业服务总线，超过一定量级还是满足不了
1.4）微服务
服务演变可以通过一个例子进行概括：
比如一个请求直接打到单体项目（地球），直接打到纵向拆分中（中国、美国），直接打到SOA（上海、北京、深圳），直接打到微服务（海淀区、闵行区、南山区、番禺区），随着粒度越来越精细所能够承担的压力也越来越分散
自动部署解决了运维压力大的问题，通过docker和k8s研发人员自己就可以搞定
微服务对于研发人员的压力增大在于原先一个服务中能调用的，现在拆分到十个微服务中，我需要的数据不在我的微服务中需要调用其它服务，又需要重新开放接口打成jar包，我的微服务再引用jar包——拆分没有具体标准拆的太细会导致通信成本过高（可以按DDD拆分）
二、Spring Cloud介绍
Config对应Nacos配置中心，Eureka对应Nacos服务发现，Zuul对应Gateway（Sping Cloud自己研发团队），Ribbon和Feign组合成OpenFeign对应Dubbo，Hystrix对应Sentinel
三、什么是服务
3.1）服务发现的概念
3.2）服务发现的两种方式——客户端服务发现
3.3）服务发现的两种方式——服务端服务发现
3.4）服务发现技术对比
3.5）Nacos架构图
Config Service表示配置中心，Naming Service表示服务发现，Nacos Core核心包，Consistency Protocol底层协议，Nacos Console控制界面网页
四、Nacos实战（代码演示单机启动）
五、Nacos核心源码解析
5.1）SpringCloud完成服务注册的时机
5.2）NacosServiceRegistry的实现原理
5.3）服务提供者地址查询原理
5.4）服务注册原理
5.5）服务发现原理
服务地址动态感知原理
