本身没有没有几代几代的概念，本文以时间段为边界进行代际的划分
一代“微”服务
以电商为例,也许有 用户模块、商品模块、订单模块、新闻模块
后来有点拆分意识 ，也许来个一个促销活动，用户模块流量激增，突然整个项目就挂掉了，就想着拆分
我们讨论拆分本质上就是讨论钱 ，拆分的理论？边界？为什么拆分？这些技术上的问题本质上就是影响了赚钱。
第一边界就是流量 ，把用户模块给拆分出来，就是把用户模块做成一个独立的api，用户模块肯定跟的用户表
手动把用户模块单独部署到一台服务器上，本来单体的时候其他用户模块关联表或者调用用户模块的代码就行了，
但现在没法调了，这时候出了RestAPI ,使用RestAPI进行调用，所以微服务拆分所谓边界的第一条就是数据库是不共享的，商品归商品数据库，用户归用户，其他还没拆的模块想要调用用户绝对不会去关联用户表，应该直接调用用户服务得到用户数据
随着发展用户服务器可能扛不住了，就又加了一台服务器继续做用户服务，这个时候当其他模块想调用的时候不知道该调那一台服务器了，于是这个时候就加一个类型ngix来做反向代理，这个反代过程中来做负载均衡
随着业务的发展，也许流量越来越大，就几乎把整个电商系统 模块都拆分成服务，变成个个服务之间产生互动，后来也逐步发展出一些比较成交成熟的网关 比如openresty、Traefik等，这个拆分的目的就是为了赚钱，并不是为了拆分而拆分
这个时候还是存在一些问题，比如说用户模块调用商品模块 延迟很高，很卡，或者错误 这个时候就需要一些机制
引入了服务降级的概念 ，说的技术化一些就是防止服务调用出现问题。
微服务中比较处理的就是服务治理这一块，虽然现在出了一些更好的架构比如k8s等，但依然没有解决好服务治理，更新更好的架构带来了便利性但也带来了服务的复杂性、运维成本等等，并没有什么架构能够解决这个问题
随着技术额发展整个微服务体系也有了雏形，包括后面的：
服务发现 如何发现服务的ip地址？
数据一致性特别重要etcd就出现了
链路监控 服务间的调用特别多，就需要一些监控手段去定位错误等
一系列的思想都是实践中总结出来的
二代微服务
以springcloud 为主的二代微服务出现了
经典的五大组件
服务发现 Eureka /nacos
客服端负载均衡 Ribbon
断路器二 Hystrix/sentilel
服务网关 Zuul springgateway
分布式配置一一Spring Cloud Config
统一了一些标准 围绕 服务治理 进行的，重要是为了保障稳定，可靠
go生态 Go-mico Go-zero等`
链路监控 Zipkin Jaeger
三代微服务
docker出现了 容器化内容
服务容器化
docker swarm
k8s横空出世!!!服务的部署特别方便 扩容 收缩特别方便
k8s帮我们完成了 部署 阔容 收缩 以及
服务发现（coreDNS）
客户端负载均衡 Service 4层负载均衡
断路器
服务网关 可以使用现成的 nginx-ingress traefik kong 等
分布式配置中心没有 但有 configmap 不能代替
手段用来越多 成本越来越高 为了k8s的 稳定 运行 目的还是赚钱
好处都有啥？ 调度特别方便，亲和性、反亲和性 软硬件等
但浏览器通过网关访问 服务与服务之间没有网关
所以有了服务网格 istio
pod 数据面
nginx-ingress 控制面
未来大趋势
k8s + service mesh
总结
k8s 是微服务吗？
答: 根本不是
那为啥k8s是三代微服务？
答： k8s提供了容器化编排方案。现代化微服务依托于k8s、云原生架构 来完成 服务治理。 以service mesh 为首的如istio、linkerd2、dapr 等 才是目前和未来的微服务方向
微服务是框架吗？
答：微服务是围绕服务会不会完蛋、怎么让它不完蛋、完蛋了怎么办、完蛋之前怎么监控 ， 这些事宜进行 “治理”的一个手段、手法。 完全不是框架 ,服务注册和发现 负载均衡 熔断 限流 重试 链路追踪 rpc 监控 分布式事务 这些都是 服务治理 的手段。 并不是等同于微服务.
