文章目录
- 一、微服务与服务治理
-
- 1、概述
- [2、Two Pizza原则和微服务团队](#2、Two Pizza原则和微服务团队)
- 3、主链路规划
- 4、服务治理和微服务生命周期
- 5、微服务架构的网络层搭建
- 6、微服务架构的部署结构
- 7、面试题
- 二、配置中心
- 三、服务监控
- 四、调用链梳理
一、微服务与服务治理
1、概述
单体应用时代，全都耦合在一起，牵一发而动全身。所有功能一起上线一起回滚。代码复杂度混乱。
微服务时代，业务模式糙快猛，敏捷编程。小步快跑，独立演进，独立部署，快速迭代。团队赋能（每个微服务有各自团队）。边界清晰，以大化小-服务拆分，三高应用-分治。
2、Two Pizza原则和微服务团队
Two Pizza原则：如果一个团队的成员，两个披萨都喂不饱他们，说明团队明显太大了 。
"大象不会跳舞" - 提倡小团队。
小团队：沟通成本低，小步快跑容易实现。（人数不会超过10个）
在微服务和敏捷的理念之下，通常是重沟通请问当，因此团队中的每个人都需要做到深度参与。
测试人员也是有很强的开发功底，会致力于测试框架的搭建。
3、主链路规划
要保障业务的最小可用性。（比如：电商的下单场景、社交的点对点消息）
主链路规划就是将有限的资源用在最核心的链路上。
根据应用的水位，进行弹性计算，确保主链路的可用性。自动/手动进行降级熔断、分段限流。
4、服务治理和微服务生命周期
远程RPC调用，A服务是如何知道B服务服务器地址的呢？B有多台服务器，A是如何从集群中选择B服务呢？B服务上下线是如何让A服务知道的呢？
总的来说，服务治理就是维护一个可用的服务列表（注册中心），并且体现服务的状态。
服务注册：每个微服务上线之后，会主动在注册中心上注册自己的IP、名称等信息。
服务发现：每个微服务都会从注册中心主动拉取所有在该注册中心上注册的服务信息。
服务续约（心跳）：每个微服务与注册中心每隔几秒发送心跳包，确保自己处于正常状态。
服务剔除：注册中心每隔一段时间进行批处理，这段时间内没收到心跳包的微服务会从注册中心剔除。
服务下线：微服务主动从注册中心剔除掉。
5、微服务架构的网络层搭建
通常来说，Unsecure Zone是可以对用户暴露的，用户可以直接访问的；Secure Zone只内部访问。
而且每个小的微服务，还会做集群部署。
6、微服务架构的部署结构
将每个微服务打包成docker镜像，部署在同一个物理机上，使用kubernetes进行快速部署。
7、面试题
问：高并发系统、资源有限、如何来保障业务顺利进行？
答：主链路规划！由面到点。业务角度规划主链路 - 流量、转化率、变现场景；漏斗模型 - 越往下越重要。
答：具体技术点：限流降级，弹性计算。
问：谈谈服务治理
答：本质是维护可用服务列表，保持服务间调用的正确性。
答：服务治理的生命周期（服务注册、服务发现、服务剔除、服务续约、服务下线）。
二、配置中心
1、为什么要配置中心
配置中心可以将配置统一管理，有配置变化可以实时推送到相关的微服务。
实现：
配置业务隔离（将具体配置文件从业务代码中抽离，放在中心化的配置中心）；
环境隔离（业务代码层并不需要关心当前部署的环境，在配置中心做配置隔离，业务代码启动时根据启动参数决定使用哪个环境的配置）；
服务隔离（中心化的配置服务，有能力识别那些配置文件属于哪些服务）。
2、配置中心高可用思考
解决单点故障问题，就需要做集群（多副本、主从、集群）。
单点故障解决方案：通过注册中心，将配置中心注册为一个微服务。来实现高可用。
配置文件本地保存一个备份，确保远程配置数据读取不到导致宕机。
总而言之，高可用的原则就是认为任何一环都不可靠，通过各种方式来提高总体的可用性。
三、服务监控
1、业务埋点的技术选型
通过业务日志，进行业务买点的处理，用于内审、统计、线上预警。
内审：后台系统、商户关键操作（银行卡、关户、密码）的关键操作都记录下来，用于内部审计。（海量数据，可查找，长期保存）
记录下来之后，根据操作员/操作资源维度进行操作查找。查出问题进行追责。
也就是说，审计数据只需要根据key来查询想要的操作记录即可，可以考虑使用CouchBase或者MongoDB等文档数据库。
线上预警：基于文件业务日志记录的，通过日志关键信息来监控关键业务流程、关键指标。
技术选型：fileBeat（收集log文件），Kafka（日志收集及分发），Logstash（日志收集、转换）、elasticSearch（存储、查询）、Kibana（图形化界面）。
2、用户行为分析（用户画像）
从个人行为数据上，分析出个人特点，从而进行一些精准推送。
日志关键信息：操作时间；页面元素；匿名/登录用户；做了什么操作。（时间、地点、人物、事件，按需记录）
3、通用埋点手段
一般就是这三种手段：后端业务埋点、前端可视化埋点、无痕埋点。
后端业务埋点：在后端代码中，进行日志打印。
可以用侵入性比较高的，手动打印日志（代码侵入高、信息完整度高、精准度高）。也可以使用AOP注解，进行统一日志（代码侵入低，信息完整度较低，精准度较低）。
前端可视化埋点/声明式埋点：使用前端的一些控件/按钮进行埋点。
比如按钮点击，触发响应函数，判断埋点开关是否开启，若开启就执行埋点函数（异步）。
对比后端业务埋点：埋点前置，降低业务侵入，降低成本。
缺点：APP更改埋点逻辑就得重新发版更新，比较麻烦。
无痕埋点：无差别记录用户行为（所有行为），异步发送后台。
记录业务事件（控件事件），需要在前端框架层面，为每个控件定义一个业务事件（每个控件要对应好业务）。
还需要后端可配（比如说APP更改埋点逻辑，只需要读取后端配置即可）。
还需要注意数据传递，前后数据关联（获取前一步操作内容），所以说无痕埋点保存数据时，还需要携带前一个页面的相关数据。
特点：埋点成本低，但是数据清洗难度高。
通常来说使用无痕埋点+可视化埋点，进行数据分析。
后端业务埋点记录关键链路。
综合使用。
4、离群点分析
四、调用链梳理
1、微服务链路梳理
微服务调用链路长，出问题之后需要找到问题的根源点。
通过报错日志，找到全局的TraceID，然后定位整条调用链路。
常用解决方案：ZipKin、skywalking。