1. 为什么使用微服务架构
- 单块应用痛点：
1. 10人以上开发容易产生代码冲突，开发效率低下
2. 代码合并之后，重新回归测试（归测试是指重复以前的全部或部分的相同测试），耗时，开发效率低
3. 上线发布需要相互配合协调等待，效率低下
4. 升级技术架构，不能随意升级，可能影响别人
- 微服务优点：
独立开发-合并代码-独立上线-独立升级架构
把一个系统拆分成abcdef 5个微服务，每个微服务分别有2-3个人开发，服务之间互相调用
国内BAT互联网大厂的微服务架构演进路线
1.优点在上边，引来的问题。 注册中心 那么服务调用使用rpc框架（远程服务调用）
多环境隔离（生产环境、集成测试环境，功能测试环境，预发布测试环境）
自动化部署
分布式事务 不同服务连接的库不一样，例如服务A更新自己的库，服务C也更新自己的库，A调C，A更新库成功，但是C更新失败
限流熔断降级 服务a调b,b调c,c调d。某个服务挂掉，其他服务也不可用。雪崩
配置中心 配置中心把配置推荐给服务
监控中心 业务指标，和服务器（CPU、内存、磁盘、网络IO、负载）
链路监控 服务a调b,b调c,c调d,b链路环节耗时，是否成功，监控性能
日志中心 单体应用向本地写就行了，微服务，需要把本地日志上报到日志中心
API网关 单体应用没必要使用网关b
安全认证 像统一限流，在网关之前
服务治理 包括注册发现、监控、链路、日志、管理管控（API网关） 前端---发送请求---网关---服务路由到----服务
几年之前（3-5年之前），注册中心使用zookeeper，服务调用使用dubbo，其他的没怎么用，国内的公司在微服务的现状。
海外硅谷互联网大厂的微服务架构演进路线
- 早些年的情况
netflix微服务开源组件整合到spring社区编程springcloud （eureka、feign、ribbon、zuul(网关)、hystrix、zipkin和sleuth链路监控、config、stream做消息中间件、contract契约测试支持、当然gateway也可以做网关、consul也是一种注册中心、还有跟spring security配合的安全认证、跟k8s配合的容器支持）
注册中心以eureka为主，consul也可以；rpc框架是feign+ribbon，相当于dubbo;监控中心和日志中心没有，监控中心国外早些年用的比较多的是zabbix,后来是felkin、现在用prometheus；日志中心没有好的开源项目，但是很多公司会用elk,分布式事务也没有原生的框架支持，早些年很多公司没有多么的重视，现在以阿里开源的seata为主。
早期除了没有监控中心、日志中心、分布式事务之外其他东西几乎都有的，springcloud可以快速搭建起来。springcloudalibaba 2-3年国内就火了（springcloud 18年大火，19年出现sprngcloudalibaba出现），中小型公司大量拥抱springcloud,大家其实只是选择了其中部分组件，直到现在，eureka，feign+ribbon、zuul、hystrix、zipkin用的还是很多，最近2年，大厂微服务都是自研，不是springcloud开源的，一部分以阿里dubbo为核心自研其他组件、中小型以dubbo为核心，自己又找了一些其他开源组件，绝大部分公司中小型公司包括传统软件公司，基本还是使用springcloud，大厂自研，部分大厂以dubbo为核心，部分中小型公司以dubbo为核心+其他的开源组件
目前国内公司的主流微服务技术栈介绍
- 之前中小公司全面拥抱springcloud，dubbo不怎么维护。最近一年多，dubbo重启活跃维护，并且融入springcloud体系，形成了springcloudalibab微服务技术组件，nacos/dubbo/seata/sentinal/rocketmq等
注册中心：nacos->eureka
| springcloudalibab | springcloud | |
|---|---|---|
| 注册中心 | nacos | eureka |
| rpc框架 | dubbo | fegin+ribbon |
| 分布式事务 | seata | - |
| 限流/熔断/降级 | sentinel | hystrix |
| API网关 | 无 | zuul (不活跃) |
springcloud netflix微服务组件更新不活跃，并且之前开源的组件不再更新了，前景不太光明
springcloud alibab组件活跃更新，社区活跃，宣讲、演讲、采访。
配置中心：携程开源的apollo,或springcloud config
链路追踪：大众点评开源的CAT（zipkin/slueth）
国外优秀开源项目：prometheus、elk、springcloud gateway
有部分公司还是springcloud netflix为主的技术栈、有部分公司尝试springcloudalibab+国内开源的组件（apollo、CAT）+prometheus+ELK+Springcloud Gateway（或者Nginx+lua、Kong、Zuul、API网关自研）
个人认可国内的是未来的主流（2-3年）、netflix不更新、不活跃、会衰退；中文文档、中文社区、交流方便活跃。
C2C电商社会化治理平台项目介绍+平台面向的痛点
consumer to consumer 可以买东西也可以卖东西 用户到用户
淘宝、京东、天猫、唯品会、拍拍网。。。
痛点： 商品、评论->违规审核(量大,平台审核困难)->社会化治理平台（用户自己投票审核，给奖励）来解决大量的举报审核的任务。
C2C电商社会化治理平台解决方案介绍
举报可能设计的场景：
1. 商品违规
2. 商品留言违规（非法广告、不良言论）
3. IM私聊不良言论
4. 不良评论
5. 论坛社区发帖回帖产生的举报
-
平台自己的预审系统（外包或者自己建立的）
-
另一部分分流到 社会化治理平台 审核
-
把举报存储在库里边（证据、判断、图片、文字说明）
-
对于每个举报圈定评审员，让他门投票，半数成立就可以封禁这个用户的评论、留言、私聊、发表的商品+给评审员发布奖励（虚拟货币，可以进行兑换商品）
私聊im设计不良言论，可能被举报
论坛，帖子发帖回帖
8 C2C电商社会化治理平台整体架构设计
举报服务调用评审员服务；再调用奖励服务
9 C2C电商社会化治理平台 微服务拆分设计
当然可以使用单体系统，但是会有问题，5人以上，代码合并冲突、等待回归测试、等待别人部署、多人协作开发效率很低，
投票制度管理：（可以针对不同的举报类型，定义不同的投票制度，比如5人3胜，3人2胜，最大等待时长，替补评审员机制，等等），提交举报接口，调用评审员服务圈定评审员，PUSH管理，举报查询接口，投票生命周期管理（发起投票、过程监控、超时等待、候补评审员管理、投票结果），调用奖励服务
评审员管理:（根据用户画像的标签，由运营去圈定一波人做评审员，其实核心在于圈定那些每周都至少会来逛一次的活跃用户，这个规则可以自行配置），评审员圈选，评审员状态管理，评审员过滤，疲劳度控制，评审员自动调整，候补评审员选择，评审结果接收
奖励服务，包含了：奖励规则配置，奖励发放，奖励兑换
10、为什么微服务化的系统架构必须要有注册中心？
11. zk、eureka、consul、nacos技术选型
zookeeper和eureka，consul用的没那么多，nacos现在用的越来越多，以后也会是一个大的趋势，但是现在可能还没那么的普及
zookeeper的基础知识以及基本的架构原理，互联网Java工程师面试突击第三季，里面是有讲过zk的一些架构原理，如果大家不了解的话，可以去看一下
zookeeper的原理，leader+follower，leader写，同步到follower，follower可以读，保证顺序一致性，就是基本尽量保证到数据一致的，主动推送，典型的CP，leader崩溃的时候，为了保证数据一致性，尽量不要读到不一致的数据，此时要重新选举leader以及做数据同步，此时集群会短暂的不可用，CP
服务注册中心选型对比的时候，其他的分布式系统选型的时候，CP，AP
P简单来说就是任何分布式系统一般都会满足，他就是分区容错性；CP，C，一致性，尽可能的去保证你读取到的数据是一致的，牺牲掉一个A，可用性，一旦leader崩溃，zk可能会有一个短时间内，几十s有可能，集群不可用，此时需要重新选举一个leader，然后再做数据同步，保证数据一致性之后再开放让你来读取
consistency，availability
关于eureka的一些架构原理，21天互联网Java工程师面试训练营（分布式篇），儒猿技术窝，重点讲解了eureka的一些架构原理
eureka的原理，peer-to-peer，大家都能写也都能读，每个节点都要同步给其他节点，但是是异步复制的，所以随时读任何一个节点，可能读到的数据都不一样，任何一个节点宕机，其他节点正常工作，可用性超高，但是数据一致性不行，AP
Consul也是基于raft算法的CP模型
Nacos也是基于raft算法的CP模型，同时也支持配置成类似eureka的AP
其实CP或者AP也都行，CP就是偶尔可能短时间不可用，AP就是可能数据不一致，两个都有问题，但是在生产环境下，无论CP还是AP其实都用的很多
其实说白了，zk作为注册中心是早期dubbo时代的标配；后续spring cloud进入国内市场，大家就都用eureka了，但是spring cloud也推荐了consul，所以consul也有不少人在用，zk、eureka、consul，其实都有人用
但是未来还是建议大家用nacos，因为nacos的功能最为完善，包括了雪崩保护、自动注销实例、监听支持、多数据中心、跨注册中心同步、spring cloud集成、dubbo集成、k8s集成，这些都支持，其他的几个技术基本都支持部分罢了
总，主要是AP CP；功能nacos功能最完善，其他只能支持nacos的一部分，长远来说还是nacos，非要选择CP还是AP，都行，非得选的话选CP。
12_SpringCloudAlibaba之 Nacos 注册中心架构原理
偏向于底层的一些网络知识的话，基础知识，互联网Java工程师面试突击第三季，主要就是讲解一些基础知识，网络的东西，TCP，HTTP，长连接和短连接，这些基础概念在里面都是讲过的
服务通过nacos server内部的open api进行服务注册，nacos server内部有一个sevice服务的概念，里面有多个instance实例的概念，同时对不同的service服务可以划归到不同的namespace命名空间下去
namespace可以是一个技术团队，比如说一个技术团队，业务A的技术团队所有的服务都放在一个namespace命名空间下面，业务B的技术团队所有的服务都放在另外一个namespace命名空间
其实说白了，注册的时候就是在注册表里维护好每个服务的每个实例的服务器地址，包括ip地址和端口号，这是最为关键的
而且一旦注册成功之后，服务就会跟nacos server进行定时的心跳，保持心跳是很关键的，nacos server会定时检查服务各个实例的心跳，如果一定时间没心跳，就认为这个服务实例宕机了，就从注册表里摘除了
其他服务会从nacos server通过open api查询要调用的服务实例列表，而且nacos客户端会启动一个定时任务，每隔10s就重新拉取一次服务实例列表，这样如果调用的服务有上线或者下线，就能很快感知到了
此外还可以对要调用的服务进行监听，如果有异常变动会由nacos server反向通知他
13、深入 Nacos 服务注册中心的内核原理
nacos本身的话，其实是完全可以脱离spring cloud自己独立运作的，但是他目前是集成到spring cloud alibaba里去的，也就是在spring cloud的标准之下实现了一些东西，spring cloud自己是有一个接口，叫做ServiceRegistry，也就是服务注册中心的概念
他是一个接口，nacos是实现了一个实现类的，也就是NacosServiceRegistry，实现了register、deregister、close、setStatus、getStatus之类的方法
自动装配是一个spring boot的一个概念，如果大家不理解的话，可以自行搜索一些资料去查阅，用最最简单的话来说，自动装配的意思，其实就是说系统启动的时候，自动装配机制会运行，实现一些系统的初始化、自动做一些事儿
比如说spring cloud alibaba，假设用dubbo开发服务，本质上是有一个自动装配类的，这个自动装配类会监听spring的ApplicationStartedEvent这个事件，其实简单理解就是服务启动的时候通过spring的一些动作，监听到某个事件就自动运行了
自动运行，就是去调用NacosServiceRegistry的register方法去进行服务注册
而且除了注册之外，还会通过schedule线程池去提交一个定时调度任务，源码如下：
this.exeutorService.schedule(new BeatReactor.BeatTask(beatInfo), beatInfo.getPeriod(), TimeUnit.MILLISECONDS)，这就是一个心跳机制，定时发送心跳给nacos server
接着会进行注册，注册的话是访问nacos server的open api，其实就是http接口，他有一个接口：http://31.208.59.24:8848/nacos/v1/ns/instance?serviceName=xx&ip=xx&port=xx，这么一个东西，也没什么特别的，这里就是访问注册接口罢了
nacos server那里是基于一个ConcurrentHashMap作为注册表来放服务信息的，直接会构造一个Service放到map里，然后对Service去addInstance添加一个实例，本质里面就是在维护信息，同时还会建立定时检查实例心跳的机制
最后还会基于一致性协议，比如说raft协议，去把注册同步给其他节点
服务发现的本质其实也是一个http接口，就是：http://31.208.59.24:8848/nacos/v1/ns/instance/list?serviceName=xx，就这么一个接口，其实也没特别的东西，然后就会启动定时任务，每隔10s拉取一次最新的实例列表，然后服务端还会监听他监听服务的状态，有异常就会基于UDP协议反向通知客户端这次服务异常变动
14_基于Nacos实现高可用服务注册中心部署 15_为什么微服务化的系统必须通过RPC框架进行通信？
构建http请求-发送http请求-接收http请求并解析
16_Feign+Ribbon、Dubbo、gRPC的选型对比
手动写一些构造HTTP请求的代码去发送给评审员服务的服务器，去调用他的http接口，总不能这样，RPC框架，举报服务在代码里就调用一个interface的接口，底层直接让RPC框架发送请求到对应的服务器上去
儒猿技术窝，《21天互联网Java工程师面试训练营（分布式篇）》，视频专栏，spring cloud的一些技术都一些讲解
feign+ribbon，spring cloud netflix技术栈，RPC调用，用的就是feign框架+ribbon做负载均衡，暴露出来的服务接口，就是最最稀松平常的基于spring mvc写的controller暴露出来的一些http接口，定义一个http的url地址
通过feign框架进行RPC调用：String result = serviceA.hello(name)，会按照http协议来组装你的请求数据，数据格式都是按照http协议里的请求来做的，http请求还还必须做一个序列化，序列化成二进制的字节流，通过底层的tcp连接发送过去
本质上服务A的部署是基于tomcat去进行部署的，tomcat会监听你指定的端口号，当别人要发送http请求给你的时候，首先必须跟tomcat建立tcp网络连接，发送http请求给tomcat，tomcat收到之后，解析出来这个http请求，交给你的spring mvc写的controller来进行处理
dubbo自己使用的一套协议，自定义协议，也可以是别的协议，肯定不是http协议，去组装请求数据，然后做一个序列化，二进制字节数组或者是字节流，都可以，通过底层的网络连接把请求数据发送过去就可以了
ServiceA这个类，调用他里面的hello()这个方法，传入name这个参数，获取result这个返回值，然后通过网络连接把响应数据按照自己的协议封装，序列化，通过网络连接发送给服务B就可以了
spring cloud feign、dubbo、gRPC，分别百度一个hello world级别的demo，自己写一下，感受和体验一下就知道了
选型对比
- fegin+ribbon轻量级，常规场景使用，前两年火，就是把接口做一个翻译成http请求，暴露服务本质是暴露springmvc写的接口，然后tomcat部署，调用的时候就是做一个方法调用。
- dubbo 很重的rpc框架，性能比feign强大，好用，是未来的主流。比较重，按照他的方式调用发布服务，底层把所有事情都做了。
- grpc 适合跨语言的场景，适合小众的场景。写一个文件。。。
18_Dubbo RPC框架集成 Nacos 注册中心
dubbo整合nacos
social -goven
report 举报
reviewer 评审员
reward 奖励
