1.优缺点
优点：
每一个服务足够内聚,代码容易理解
开发效率提高,一个服务只做一件事
微服务能够被小团队单独开发
微服务是松耦合的,是有功能意义的服务
可以用不同的语言开发,面向接口编程
易于与第三方集成
微服务只是业务逻辑的代码,不会和HTML,CSS或者其他界面组合
开发中,两种开发模式
前后端分离
全栈工程师
可以灵活搭配,连接公共库/连接独立库
缺点
分布式系统的负责性
多服务运维难度,随着服务的增加,运维的压力也在增大
系统部署依赖
服务间通信成本
数据一致性
系统集成测试
性能监控
2.如何实现服务注册和发现
首先，要有一个注册中心（eureka，zookeeper）
然后，把同一个业务的多个服务的服务名和ip注册到注册中心（服务名称都是一样，ip不一样）
最后，当前端有人访问，就会发送一个服务名到注册中心，注册中心就会用轮询算法选择一个服务，前端用来访问（这就实现了负载均衡）
3.微服务特点
• 服务组件化
每个服务独立开发、部署，有效避免一个服务的修改引起整个系统重新部署。
• 技术栈灵活
约定通信方式，使得服务本身功能实现对技术要求不再那么敏感。
• 独立部署
每个微服务独立部署，加快部署速度，方便扩展。
• 扩展性强
每个微服务可以部署多个，并且有负载均衡能力。
• 独立数据
每个微服务有独立的基本组件，例如数据库、缓存等。
4.微服务不足
• 沟通成本
• 数据一致性
• 运维成本
• 内部架构复杂性
还要面对：
• 大量服务如何治理
• 如何部署
• 如何监控
• 数据和事务
5.单体应用 vs 微服务
单体架构优势：
• 易于部署
• 易于测试
单体架构不足：
• 代码膨胀，难以维护
• 构建、部署成本大
• 新人上手难（开发上手难，因为代码非常庞大，可读性较低）
应用场景
微服务：重量级应用，功能非常多，例如京东、淘宝
单体服务：轻量级应用，功能不是非常多的
6.访问流程（重点）
客户访问前端，负载均衡器是为了给网关做分发调度来减少压力同时也会存放一些静态资源，以及高可用
网管作为统一入口，根据不同的请求给后方不同的服务，服务都会注册在注册中心，网关是通过注册中心来找相对应的服务，注册中心并响应一个（如果某个服务起了3个，也只会相应一个来提供服务），
服务和服务之间也需要相互之间的调用，例如下一个订单，那么支付的时候就需要调用支付服务，服务和服务的通讯一般是通过RPC或者MQ（消息队列）
存储方面MQ（消息队列）解决服务之间的通讯，分布式存储解决一部分静态资源之类的，redis解决事务的一致性，配置中心用来分发每个服务所需要的配置（例如支付服务可能调用mysql之类的这种的）
7.全链路监控
随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。这些服务可能不同编程语言开发，不同团队开发，可能部署很多副本。因此，就需要一些可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题。全链路监控组件就在这样的问题背景下产生了。全链路性能监控 从整体维度到局部维度展示各项指标，将跨应用的所有调用链性能信息集中展现，可方便度量整体和局部性能，并且方便找到故障产生的源头，生产上可极大缩短故障排除时间。
8.全链路监控能解决什么问题？
• 请求链路追踪：通过分析服务调用关系，绘制运行时拓扑信息，可视化展示
• 调用情况衡量：各个调用环节的性能分析，例如吞吐量、响应时间、错误次数
• 容器规划参考：扩容/缩容、服务降级、流量控制
• 运行情况反馈：告警，通过调用链结合业务日志快速定位错误信息
9.全链路监控的选择依据
全链路监控系统有很多，应从这几方面选择：
• 探针的性能消耗
APM组件服务的影响应该做到足够小，数据分析要快，性能占用小。
• 代码的侵入性
即也作为业务组件，应当尽可能少入侵或者无入侵其他业务系统，
对于使用方透明，减少开发人员的负担。
• 监控维度
分析的维度尽可能多。
• 可扩展性
一个优秀的调用跟踪系统必须支持分布式部署，具备良好的可扩展
性。能够支持的组件越多当然越好。
主流系统：zipkin、skywalking、pinpoint
红色标注为无代码侵入
