一、 什么是微服务架构
1、 一组小的服务
2、 独立的进程
3、 轻量级通信
4、 基于业务能力
5、 独立部署
6、 无集中式管理
二、 利与弊
利：
1、 强模块化边界
2、 可独立部署
3、 技术多样性
弊：
1、 分布式复杂性
2、 最终一致性
3、 运维复杂性
4、 测试复杂性
三、康威法则和微服务——微服务的理论基础就是康威法则
康威法则：设计系统的组织以及产生的架构等价于组织的组织架构。或者说：设计系统的组织以及产生的设计等价于组织的沟通结构。
https://www.jianshu.com/p/aca81cbf861b
原文：Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)
翻译：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。
第一定律
Communication dictates design 组织沟通方式会通过系统设计表达出来
第二定律
There is never enough time to do something right, but there is always enough time to do it over.
时间再多一件事情也不可能做的完美，但总有时间做完一件事情
第三定律
There is a homomorphism from the linear graph of a system to the linear graph of its design organization
线型系统和线型组织架构间有潜在的异质同态特性
第四定律
The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems
大的系统组织总是比小系统更倾向于分解
说白了，康威法则的真正含义就在于，在项目达到一定规模后，团队规模和单个项目复杂度之间产生矛盾，生产力低下。多个团队维护同一个项目，在集成时往往需要各个团队的相互配合，而如果将一个项目拆分成多个小项目后，每个团队只负责该一个小项目，就能避免许多不必要的麻烦。——所以说架构师不仅仅是要关心技术架构还要关心组织架构（人员）。
四、企业应该在什么时候开始考虑引入微服务？
一般的，团队规模达到百人时，就必须要引入微服务了。
在初始阶段要单块应用优先，随着功能的复杂性变大，一块一块的将不断变复杂的模块拆分出来成为微服务。
五、什么样的组织架构更适合微服务
跨职能微服务产品团队：团队内部能够形成闭环，更快的响应需求，产品迭代。
Neflix前总监：微服务架构本质上是组织架构的重组。
六、如何理解阿里巴巴提出的微服务中台战略？
阿里巴巴提出的理念：大中台，轻(小)前台。这就是中台战略，说直白点就是：让前段的业务更小更灵活，根据市场的变化用户的需求快速的、不断的演化出新的应用，当下面的中台（包括业务中台和技术中台）做的非常完善时，对上层应用的支撑能力就越强，目标就是赋能业务的创新，快速响应市场的需求。
Paas层就是微服务的基础设施层。
七、如何给出一个清晰简洁的服务分层方式
BFF其实是Backend for Frontend的简称，中文翻译是为前端而开发的后端，它主要由前端团队开发（后端微服务一般由后端团队开发）。BFF可以认为是一种适配服务，将后端的微服务进行适配（主要包括聚合裁剪和格式适配等逻辑），向无线端设备暴露友好和统一的API，方便无线设备接入访问后端服务。https://www.sohu.com/a/236506677_673711
八、微服务总体技术架构体系是怎样设计的
九、微服务最经典的三种服务发现机制
1、传统基于LB的模式
单独的LB（F5、Nginx），配置域名执行后台多个服务，这个LB往往存在单点问题；另外消费者调用提供者时会有性能损耗。
2、进程内LB模式
3、主机独立LB模式
十、微服务 API 服务网关
1、 原理
网关前需要增加一层负载均衡器，因为负载均衡的存在，网关就成为无状态的。无状态的好处就在于网关可以部署很多，无单点问题，增强系统的稳定性和可用性。
网关的主要功能：反向路由、认证安全、限流熔断、日志监控。
2、开源网关 Zuul
Zuul的总体流程架构：
Zuul网关的核心就是一个Servlet。
ZuulFilter Runner：管理了所有的过滤器，这些过滤器分为三个层次——前置路由过滤器(Pre routing filters)、路由过滤器(routing filters)、后置路由过滤器(Post routing filters)
前置路由过滤器：日志处理、转发后台请求等；
路由过滤器：找到后台服务调用请求等；
后置路由过滤器：日志处理、统计、审计等
Neflix在设计网关时，考虑到网关的流量大、重要性高，不能经常更新，但又要满足经常变动的需求，所以实现了动态插拔的过滤器功能，过滤器是Groovy脚本过滤器。并实现了灵活的上传加载机制：
Filter publishFilter Persistence(DB)—>后台有个Filter puller(定期pullDB，将新的filter上传到Filter目录中)—>Filter Directory——>Filter Manager定期扫描这个目录——>Filter Loader将扫描到新的Filter加载到Filter Runner中生效
如果要在各个Filter之间共享一些信息，那么可以通过Request Context组件。
网关总体的流程和调用链如下图：
十一、 Netflix微服务路由发现体系
服务注册中心：Netflix开源组件Eureka（开源的还有Consul等）
网关：Netflix开源组件Zuul
这两大组件，支撑了整个Netflix的服务路由发现体系；基础服务层也即中间层服务；聚合服务层也叫边界服务层。
十二、集中式配置中心的作用和原理是什么？
为了使得配置标准化、格式统一化，缩短上线周期，快速响应变化，通过审计功能可以追溯问题，所以提出了集中式配置中心。
数据库连接字符串、缓存连接字符串、消息队列的连接字符串、动态调整的参数（客户端的超时、限流的阈值）、业务的开关配置等。
实时更新，方式有两种：push和pull。pull保证能够拿到最新配置，push则不一定，因为如果因为网络原因，push没成功，则可能丢失最新配置。
常用的产品：百度分布式配置管理平台-Disconf；Spring cloud config；携程的Apollo配置中心等等。
特色：在客户端本地有缓存，实现高可用。
https://github.com/ctripcorp/apollo
十三、微服务通讯方式 RPC vs REST
十四、微服务框架需要考虑哪些治理环节？
1、 配置集成
2、 后天服务集成DB、MQ、Cache
3、 服务注册发现
4、 软负载路由——用以支持灰度发布、蓝绿发布等
5、 日志
6、 Metrics——对服务的调用量、延迟、出错量等监控。
7、 调用链监控
8、 限流熔断
9、 安全&访问控制 —— 黑名单、权限限制等
10、REST/RPC —— 框架最好支持这两种
11、序列化 XML/JSON/二进制 —— 最好都支持
12、代码生成 —— 大规模开发时，推崇一种契约驱动的开发方式：定义好契约后利用代码生成的方式自动生成客户端和服务端代码。
13、统一异常处理 —— 异常标准化
14、文档
微服务框架就是要把上面的这些功能沉淀下来，变成平台的一部分，开发人员只专注于业务的实现。
可以参考阿里巴巴的Dubbo是如何融合这些功能的。
十五、微服务监控系统分层和监控架构
十六、微服务的调用链监控该如何选型？
十七、微服务的容错限流是如何工作的？
引用：
http://www.uml.org.cn/wfw/201906063.asp?artid=22057
通过hystrix可以解决雪崩效应问题，它提供了资源隔离、降级机制、融断、缓存等功能。
- 资源隔离：包括线程池隔离和信号量隔离，限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其他服务调用。
- 降级机制：超时降级、资源不足时(线程或信号量)降级，降级后可以配合降级接口返回托底数据。
- 融断：当失败率达到阀值自动触发降级(如因网络故障/超时造成的失败率高)，熔断器触发的快速失败会进行快速恢复。
- 缓存：返回结果缓存，后续请求可以直接走缓存。
- 请求合并：可以实现将一段时间内的请求（一般是对同一个接口的请求）合并，然后只对服务提供者发送一次请求。
十八、Docker 容器部署技术 & 持续交付流水线
十九、容器集群调度和基于容器的发布体系
