Nacos——服务发现

一、服务的演变之路

1.1）单体架构（all in one）

单机架构在组别开发时会碰到代码版本提交和获取最新版本代码时组别成员之间产生很多冲突，在测试时不同服务提交新版本都会导致整个测试环境的重启（某一个服务需要在测试环境远端Debug）从而拖慢测试进度——类似于Oracle这种大型单体修改一个小功能重启需要二三十分钟

单体项目缺点：

某些服务比如库存更加依赖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

将系统为粒度改成提取出来的基础服务为粒度打破业务壁垒，上层的系统不再像系统而像是不同服务拼装出来的一个虚拟盒子，比如订单系统需要订单ID为3的其它信息不是将请求直接发给其它系统而是通过ESB企业服务总线（通常称为BUS）转发给其他系统，其他系统根据订单ID提供自己掌握的信息到BUS，再由订单系统BUS去消费

随着服务量越来越大SOA的承载力全部压在ESB企业服务总线，超过一定量级还是满足不了

1.4）微服务

服务演变可以通过一个例子进行概括：

比如一个请求直接打到单体项目（地球），直接打到纵向拆分中（中国、美国），直接打到SOA（上海、北京、深圳），直接打到微服务（海淀区、闵行区、南山区、番禺区），随着粒度越来越精细所能够承担的压力也越来越分散

几百个war包导致上线需要排队，排到你负责项目上线时将需要的资源配置和上线的war包交给运维进行调试有问题当前解决，短时间解决不了还需要轮到下一个排队的人，自己回去改完再排队很麻烦

自动部署解决了运维压力大的问题，通过docker和k8s研发人员自己就可以搞定

微服务对于研发人员的压力增大在于原先一个服务中能调用的，现在拆分到十个微服务中，我需要的数据不在我的微服务中需要调用其它服务，又需要重新开放接口打成jar包，我的微服务再引用jar包——拆分没有具体标准拆的太细会导致通信成本过高（可以按DDD拆分）

微服务更多关注服务之间是不是做到了完全的解耦，类似于单一职责原则，而在重用性方面更关注解决大服务的重用，一些微小服务的重用并不是那么着急解决

二、Spring Cloud介绍

Netflix稳定性强于Alibaba，Alibaba功能更加丰富但需要更强的研发能力处理发现的Bug

Config对应Nacos配置中心，Eureka对应Nacos服务发现，Zuul对应Gateway（Sping Cloud自己研发团队），Ribbon和Feign组合成OpenFeign对应Dubbo，Hystrix对应Sentinel

三、什么是服务

3.1）服务发现的概念

有问题自动重启之后IP改变，服务注册中心通过心跳实时检测更新列表并将列表发送给需要获取服务列表的机器

3.2）服务发现的两种方式——客户端服务发现

不常用

3.3）服务发现的两种方式——服务端服务发现

常用，负载均衡在网关做的概率大

3.4）服务发现技术对比

CP高一致性；AP高可用性，两者是冲突的无法同时保证，比如分布式锁配置Redis集群的一致性，比如Redis集群A、B、C，B宕机了但是Redis的高可用性会通过A、C继续提供服务，那等B恢复了需要同步A、C的数据，那还没同步完之前请求打到B就没办法保证数据高一致性——解决方式是通过zk保证分布式锁的高一致性，zk发现集群有问题就不接请求了，等集群恢复再接收