持续更新中
实现的算法有四种，分别是计算器法、滑动窗⼝算法、漏桶算法、令牌桶；其中后两种使⽤较多，
漏桶算法：由两部分组成，漏点+桶。⽐如桶(队列)只能存放10个请求，以固定漏点(线程)处理请求。超出桶⼤⼩的请求则丢弃；缺点是⽆法应对突发流量。 令牌桶算法：独⽴线程(协程)以固定速率⽣产令牌丢尽桶⾥，若桶满则丢弃。客户端发起请求先从桶拿令牌，若⽆，则丢弃。拿到令牌的请求则可打到下游服务，缺点是：若桶设置⽐较⼤，会对下游服务压⼒。
⼆、Go-Micro各组件功能
⼋⼤组件(interface)，可以根据需求重新实现
Server：向注册中⼼注册⾃⼰；监听客户端调⽤；处理Brocker所关注(订阅)的topic推送过来的消息；默认是rpc实现⽅式，还有grpc 和http⽅式。
Client：请求服务的接⼝，封装了Transport和codec进⾏rpc调⽤，也封装了Brocker进⾏信息发布；默认是rpc实现⽅式，还有grpc 和http⽅式。
Register：服务注册及发现，⽬前实现的consul,mdns, etcd,etcdv3,zookeeper,kubernetes.等等，watch会监听server的新注册节点或者消亡节点，来提醒客户端更新Service信息
Broker：消息队列处理消息的发布和订阅。⽐如订单完成了；只需提交订单信息给订单topic即可，其他需要的微服务(物流、营销)只需关注这个订单tpoic即可。broker默认实现⽅式http⽅式，尽量使⽤成熟的消息队列实现⽅式：kafka、nsq、rabbitmq、redis Selector：调度器，根据何种负载策略选择后端Server并返回 Codec：消息编解码器，使⽤原protobuf(默认)、jsonrpc、mercury还是json等数据传输格式
Transport：服务之间通信接⼝，服务发送(Dial)和接收(Listen)的接⼝，是使⽤默认的实现⽅式还是对⾃⼰对接⼝进⾏实现均可Service：client和server的封装，包含了⼀系列使⽤⽅法取初始化Server和Client，借此可以简单创建⼀个rpc服务。
三、什么是Hystrix？
在微服务中可能存在多个服务连锁调⽤，⽐如A->B->C。若某个服务压⼒暴增，可能导致后续服务连
锁被压垮，所以断路器就是保证此场景，不⾄于⼀个节点发⽣问题导致所有节点发⽣问题。
Hystrix是⼀个分布式容错框架。可以阻⽌故障的连锁反应，实现熔断；调⽤服务失败后快速失败，实现优雅降级；提供实时监控和告警。
四、Hystrix是如何实现容错的？
资源隔离：
线程隔离：Hystrix会给每个Command分配⼀个单独线程池，这样在进⾏单个服务调⽤的时候，就可以在独⽴线程池⾥进⾏，⽽不会对其他线程池造成影响。
信号量隔离：客户端需向依赖服务发起请求时，⾸先要获取⼀个信号量才能真正发起调⽤，由于信号量的数量有限，当并发请求量超出信号量个数，后续请求则会拒绝，进⼊fallback流程。信号量隔离主要通过控制并发请求量，防⽌请求线程⼤⾯积阻塞，从⽽达到限流和防⽌雪崩的⽬的。
熔断和降级(调⽤服务失败后快速失败，实现优雅降级)
熔断是防⽌异常不扩散，保证系统的稳定性
降低是调⽤失败的补救逻辑，降低服务接⼝优先级，以低频率的尝试服务，⽽不是直接报错或者停⽌服务；若服务尝试成功，则逐渐回升服务接⼝优先级。
五、Hystrix容错具体实现流程
通过HystrixCommand或者HystrixObservableCommand将所有外部系统(或称依赖)包装起来，整个包装对象是单独运⾏在⼀个线程之中(这是典型的命令模式)
请求超过你定义的阈值(超时请求)
为每个依赖关系维护⼀个⼩的线程池(或信号量)；如果他满了，那么依赖的请求将⽴即被拒绝，⽽不是排队等待。
统计成功，失败(由客户端抛出的异常)，超时和线程拒绝次数。
地沟油提炼
当超时达到⼀定次数打开断路器，可以在⼀定时间内停⽌对特定服务的所有请求(后⾯的请求直接熔断)，如果服务的错误百分⽐通过阈值，⼿动(改配置，会实时监听)或⾃动关闭断路器。
上⾯步骤出现被拒绝、链接超时或断路器打开，则直接fallback逻辑。
六、什么是服务雪崩、什么是服务限流？
1、当服务A调⽤服务B，服务B调⽤C，此时⼤量请求突然请求A，假如A能抗住，但是C抗不住，导致C请求堆积，导致B请求堆积，导致A 不可⽤，这就是服务雪崩，解决⽅式就是服务降级和服务熔断
2、服务限流是指在⾼并发场景请求下，为了保护系统，对访问服务的请求数量进⾏控制，从⽽让系统不被⼤量请求压垮，在秒杀中，限流是⾮常重要的
七、什么是服务降级、什么是服务熔断？
降级是解决系统资源不⾜和海量业务请求之间的⽭盾
当系统负载过重时，可以关闭某个服务或限流某个服务来减轻系统压⼒。如28原则关闭⾮核⼼功能服务。
熔断是保护业务系统不被外部⼤流量或下游系统异常⽽拖垮。
若开启熔断，服务A调⽤下游服务B异常时，上游服务为了保证⾃⼰不受影响，不再调⽤服务B直接返回⼀个结果，减轻服务A和B的压⼒，直⾄B恢复。
相同点：两者都是为了防⽌系统崩溃，均可使某些功能不可⽤。
异同点：熔断是下游服务故障触发，降级是为了降低系统负载。
⼋、如何拆分微服务？
拆分微服务的时候，为了尽量保证微服务的稳定，会有⼀些基本的准则：
1、微服务之间尽量不要有业务交叉。订单微服务不要对⽤户信息有操作，由⽤户微服务操作。
2、微服务之间只能通过接⼝进⾏服务调⽤，⽽不能绕过接⼝直接访问对⽅的数据；订单需要获取⽤户信息，只能调⽤户微服务接⼝。若订单微服务直接DB查数据，万⼀⽇后对表进⾏改造，订单微服务也要跟着改。
3、⾼内聚、低耦合。⾼内聚要求功能⾜够内敛，⽐如⽤户数据只能由⽤户微服务管理。低耦合只会对⾃⼰业务变动进⾏更改，对其他微服务的变动不为所动。⽐如订单微服务不会因⽤户数据变动⽽跟着变，保证获取信息接⼝是稳定的即可。
九、怎样设计出⾼内聚、低耦合的微服务？
⾼内聚低耦合，是⼀种从上⽽下指导微服务设计的⽅法。意思是不光体现微服务之间，也要体现在微服务的内部，MVC每⼀层。
例⼦：
处理下单请求，通过订单微服务controller(组装业务的所有逻辑，dao、dto等)调⽤service进⾏⽤户数据获取，service具体要怎么获取，是使⽤ ⽤户同步接⼝调⽤的⽅式还是异步事件驱动⽅式获取⽤户信息？，controller不管，返回给我个实现即可。
处理完成后，物流、营销等微服务需要获取下单信息，订单微服务可不管，把订单信息往MQ⼀扔就完事了。需要的微服务去关注即可。这样双⽅的耦合就降低了。
实现⾼内聚低耦合的⼯具主要有同步的接⼝调⽤和异步的事件驱动(例如MQ)两种⽅式
⼗、有没有了解过DDD领域驱动设计？
DDD(Domain-Driver-Design)是⾯对软件复杂之道。随着微服务体系越来越⼤，业务越来越复杂，微服务体系也⾯临着如单体架构过于复杂的问题。所以业界需要⼀种思想来把微服务复杂度进⾏降低。
10.1 什么是领域？
⽐如有⼀张商品表Product
create table`product`(
`price`float(7,2)COMMENT'商品价格'
`store`smallint(20)COMMENT'商品库存',
)
商品服务形成⼀个领域，有⾃⼰的实体及实体的⽅法
物流服务形成⼀个领域，也有⾃⼰的实体及实体的⽅法
type Product struct{
`price`float64`json:"price`
}
func(o *Product )SetPrice(){}// 设置价格
type Logistics struct{
`store`string`json:"store`
}
func(o *Order)SetStore(){}// 修改库存
10.2 什么是驱动设计？
音箱的制作像上⾯的例⼦，商品服务想要动库存必须调物流服务提供的接⼝，⽽不能跨过这个领域，⾃⼰来改DB。
驱动设计的意思是领域间通过同步的接⼝或者异步驱动事件进⾏服务调⽤。
⼗⼀、什么是中台？
中台就是将各个业务线中可复⽤的功能抽取出来，剥离个性，提取共性，形成可复⽤的组件。像每⽇优鲜、美团团购等都是由之前积累电商组件进⾏拼凑的应⽤场景，像这些组件就是中台。
中台分为业务中台、数据中台和技术中台。
业务中台：例如⽤户管理、权限管理、移动⽀付等功能组件，⽐如⽀付宝的⽀付系统在哪都可使⽤。
数据中台：例如芝⿇信⽤、⼤数据杀熟等
技术中台：封装技术框架、收银中台、风控中台等
DDD和中台结合，可以以DDD的领域界限划分不同的中台
⼗⼆、分布式事务如何处理？如何保证事务⼀致性？
⼗三、分布式、SOA、微服务之间有什么关系和区别
1、分布式是指将单体架构中各个部分拆分，然后部署到不同机器或进程中去，SOA和微服务基本都是分布式架构
2、SOA是⼀种⾯向服务的架构，系统的所有服务都注册在总线上，当调⽤服务时，从总线上查服务信息，然后调⽤
3、微服务是⼀个更彻底⾯向服务的架构，将系统各个功能进⾏抽象成⼩⼩的应⽤程序，基本保持⼀个应⽤对应⼀个服务的架构
⼗四、项⽬如何保证微服务敏捷开发？微服务的链路追踪、持续集成、AB、蓝绿发布要怎么做？
敏捷开发：⽬的就是为了提⾼团队交付效率、快速迭代、快速试错。具体的内容可以通读这篇⽂章即可
链路追踪：为故障发⽣时，从众多的微服务进⾏排查的⽅式
基于⽇志：形成全局事务ID，落地到⽇志⽂件。Filebeat-Logstash-Elasticsearch形成⽇志报表
基于MQ：通常需要架构⽀持。经过流式计算形成⼀些可视化的结果
持续集成：例如使⽤Jenkins，配置主机地址和密钥，然后构建流⽔线，配置git地址和密钥，也可以配置⼀些shell脚本、构建完成动作(发邮件、触发其他流⽔线)等等。也可以在git上配置钩⼦触发流⽔线。
AB发布：蓝绿版本，若⽤k8s部署集服务，可以修改镜像地址后再进⾏扩容副本，此时就会出现AB版本。意义新⽼版本过度。
⾦丝雀发布：若使⽤k8s部署集服务，可修改镜像地址后进⾏调⽤k8s api进⾏回滚操作并⽴即停⽌，此时仅有⼀个少量容器接收到此消息进⾏版本回退出现⾦丝雀。意义是让部分⼈使⽤新功能，防⽌⼤⾯积差评、异常。
⼗五、什么是微服务、及优缺点？
微服务就是⼀种架构⽅式，将⼤型单体应⽤根据⾜够内聚功能进⾏拆分成较⼩的单元，降低系统的复杂度。
优点：
⾼内聚低耦合：服务之间业务⽆关联，服务之间通过接⼝/事件驱动
部署更灵活：每个服务应⽤是独⽴的项⽬，可以独⽴启动，⽆需其他服务依赖。
技术更灵活：服务只要实现接⼝的⽅法即可，⽆需关注实现技术，利于对技术的迭代升级。
提⾼代码复⽤：例如订单微服务可被物流、库存、营销等微服务调⽤。
便于快速组件团队：新成员⽆需像以往关注单体系统各个部分的了解。仅需对专门的微服务进⾏了解即可
缺点：
服务调⽤复杂性提⾼：容易出现服务雪崩等问题
不利于分布式事务：尽量不使⽤微服务事务，建议使⽤事务最终⼀致性。例如平安证券，提现的时候你会发现钱到银⾏卡但是APP⾥仍⽆ 改变，它会把这笔钱先变成Unavailable，待异步事件驱动⽅式获取到操作成功消息后，才减少这笔钱(事后对账的⽅式)
测试、运维难度提升：业务出问题，到底是哪个微服务出错了？需要解决多个环境依赖。
微服务会随着需求的增加逐渐膨胀复杂。出现了DDD和中台解决⽅案
⼗六、Docker的Namespace和Cgroup
NameSpace机制是⼀种资源隔离⽅案，使PID、IPC、⽹络等资源进⾏隔离，仅属于特定的Namespace
Cgroup是控制容器中的进程对CPU、内存、磁盘、⽹络等资源控制。控制对资源的消耗限制
胎圈用钢丝
⼗七、Docker与虚拟机
1、容器不需要引导操作系统内核，因此可以在不到⼀秒就运⾏
智能抄表2、容器的虚拟化⽆需其他软件，主机上所有容器共享主机调度程序，节省额外资源的请求
3、容器的镜像更⼩，使⽤分层的⽂件系统(联合⽂件系统UnionFS)
阿比丹 艾山
4、容器的资源管理通过cgroup实现，容器资源消耗不允许超出cgroup分配的
⼗⼋、Docker⽹络模型
球形接头host
container
⼗九、简单介绍K8s源码，讲下你最熟悉的模块
k8s在github是这样介绍的：⽣产级别容器调度和管理。使⽤standard goalng project layout(标准golang项⽬布局)。
根⽬录下有api、cmd、build、docs⽬录等，其中cmd⽬录是存放可执⾏⽂件的⼊⼝代码，每个可执⾏⽂件对应⼀个main。
cmd⽬录⾥⾯的组件有kube-apiserver、kube-proxy、kebe-schedule、kube-controller-manager、kebelet、kubectl、kubeadm等组件
因为kubeadm是部署k8s应⽤的，当时产品上使⽤了k8s，需要做⾃动化部署，故翻了⼀下源码。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议