01讲到底什么是微服务？
微服务架构是将复杂臃肿的单体应用进行细粒度的服务化拆分，每个拆分出来的服务各自独立打包部署，并交由小团队进行开发和运维，从而极大地提高了应用交付的效率，并被各大互联网公司所普遍采用。
02讲从单体应用走向服务化
核心是服务的拆分
纵向：业务纬度
横向：独立功能
03讲初探微服务架构
04讲如何发布和引用服务？
-
RESTful API
-
XML配置
-
IDL文件
05讲如何注册和发现服务？
06讲如何实现RPC远程服务调用？
-
通信框架。它主要解决客户端和服务端如何建立连接、管理连接以及服务端如何处理请求的问题。
-
通信协议。它主要解决客户端和服务端采用哪种数据传输协议的问题。
-
序列化和反序列化。它主要解决客户端和服务端采用哪种数据编解码的问题。
07讲如何监控微服务调用？
监控的对象是什么？
业务、jvm、操作系统
具体监控哪些指标？
次数 qps
响应时间 tp90 tp99 ..
从哪些维度进行监控？
集群、机器、时间、核心
监控系统主要包括四个环节：数据采集、数据传输、数据处理和数据展示
08讲如何追踪微服务调用？
服务追踪系统的鼻祖：Google发布的一篇的论文Dapper, a Large-Scale Distributed Systems Tracing Infrastructure，里面详细讲解了服务追踪系统的实现原理。它的核心理念就是调用链：通过一个全局唯一的ID将分布在各个服务节点上的同一次请求串联起来，从而还原原有的调用关系，可以追踪系统问题、分析调用数据并统计各种系统指标。
基本概念：traceId、spanId、annonation等
traceId是用于串联某一次请求在系统中经过的所有路径，spanId是用于区分系统不同服务之间调用的先后关系，而annotation是用于业务自定义一些自己感兴趣的数据，在上传traceId和spanId这些基本信息之外，添加一些自己感兴趣的信息。
09讲微服务治理的手段有哪些？
服务治理的手段是最常用的手段，它们从不同角度来确保服务调用的成功率。节点管理是从服务节点健康状态角度来考虑，负载均衡和服务路由是从服务节点访问优先级角度来考虑，而服务容错是从调用的健康状态角度来考虑，可谓是殊途同归。
10讲Dubbo框架里的微服务组件
11讲服务发布和引用的实践
12讲如何将注册中心落地？
13讲开源服务注册中心如何选型？
满足两个条件
高可用：
集群部署
数据一致性：
CP型注册中心
ZooKeeper，etcd，Consul
AP型注册中心
Eureka
14开源RPC框架如何选型
完整的RPC框架主要有三部分组成：通信框架、通信协议、序列化和反序列化格式
dubbo
spring cloud
thrift
15讲如何搭建一个可靠的监控系统？
ELK
16讲如何搭建一套适合你的服务追踪系统？
业界比较有名的服务追踪系统实现有阿里的鹰眼、Twitter开源的OpenZipkin，还有Naver开源的Pinpoint，它们都是受Google发布的Dapper论文启发而实现的。
17讲如何识别服务节点是否存活？
心跳开关保护机制
服务节点摘除保护机制
静态注册中心
18讲如何使用负载均衡算法
随机算法
轮询算法
加权轮询算法
最少活跃连接算法
一致性hash算法
19讲如何使用服务路由？
服务路由就是服务消费者在发起服务调用时，必须根据特定的规则来选择服务节点，从而满足某些特定的需求。
20讲服务端出现故障时该如何应对？
三种故障：集群故障、单IDC故障、单机故障，并且针对这三种故障我给出了分别的解决方案，包括降级、限流、流量切换以及自动重启。
21讲服务调用失败时有哪些处理手段？
超时、重试、双发、熔断
22讲如何管理服务配置
在实际选择的时候，Spring Cloud Config作为配置中心的功能比较弱，只能通过git命令操作，而且变更配置的话还需要手动刷新，如果不是采用Spring Cloud框架的话不建议选择。而Disconf和Apollo的功能都比较强大，在国内许多互联网公司内部都有大量应用，其中Apollo对Spring Boot的支持比较好，如果应用本身采用的是Spring Boot开发的话，集成Apollo会更容易一些。
23讲如何搭建微服务治理平台
可以说一个微服务框架是否成熟，除了要看它是否具备服务治理能力，还要看是否有强大的微服务治理平台。因为微服务治理平台能够将多个系统整合在一起，无论是对开发还是运维来说，都能起到事半功倍的作用，这也是当前大部分开源微服务框架所欠缺的部分，所以对于大部分团队来说，都需要自己搭建微服务治理平台。不过好在微服务治理平台本身的架构并不复杂，你可以根据自己的实际需要，来决定微服务治理平台具备哪些功能。
24讲微服务架构该如何落地
总结来讲就是，首先你必须组建一支合适的技术团队，这其中不仅要包含资深的架构师，还需要包含业务的开发者。在选择业务进行微服务架构改造时，不能追大求全，正确的做法应当是先以一个适当规模的业务进行微服务改造，走完整个微服务架构落地的过程，从而找出问题，不断打磨到成熟可用的状态，再推广到更多更重要的业务当中。在改造的过程中，要做好技术取舍，以团队人员的实际情况以及业务的实际需求为准绳，切忌追新立异，避免给业务引入不可控因素，留下“架构债”。同时，微服务架构的过程，也是团队组织变革的过程，传统意义上的开发、测试和运维明确的分割线会被打破，出现一种DevOps工程师的角色，他需要对服务全生命周期负责。为了做到这一点，就需要一个统一的微服务治理平台，融合服务治理和运维的各种功能。
25讲微服务为什么要容器化？
基础环境层。这一层定义操作系统运行的版本、时区、语言、yum源、TERM等。
运行时环境层。这一层定义了业务代码的运行时环境，比如Java代码的运行时环境JDK的版本。
Web容器层。这一层定义了业务代码运行的容器的配置，比如Tomcat容器的JVM参数。
业务代码层。这一层定义了实际的业务代码的版本，比如是V4业务还是blossom业务。
26讲微服务容器化运维：镜像仓库和资源调度
镜像仓库帮我们解决的是Docker镜像如何存储和访问的问题，在业务规模较大时，各个业务团队都需要搭建自己的私有镜像仓库。类似Harbor这种开源解决方案能很好地解决权限控制、镜像同步等基本问题，关于高可用性的要求以及上云支持等业务场景，你可以参考我给出的解决方案，它是经过微博实际线上业务验证过的。
资源调度帮我们解决的是如何整合来自不同的集群的资源的问题，如果你的业务不止在内部私有云上部署，在公有云上也有部署，甚至是采用了多家公有云，那么资源的调度将会是非常复杂的问题，尤其是在公司内部已经存在一套对接内部集群的运维管理平台的情况下，是升级已有的运维平台以支持公有云，还是直接开发另外一套新的能够实现多云对接，这是一个很现实的问题。我的建议是单独开发一套新的运维平台先来接管公有云，然后逐步迁移内部集群的管理工作到新的运维平台中。
27讲微服务容器化运维：容器调度和服务编排
Kubernetes
28讲微服务容器化运维：微博容器运维平台DCP.html
29讲微服务如何实现DevOps
要实现DevOps，就必须开发完成代码开发后，能自动进行测试，测试通过后，能自动发布到线上。对应的这两个过程就是CI和CD，具体来讲就是：
-
CI（Continuous Integration），持续集成。开发完成代码开发后，能自动地进行代码检查、单元测试、打包部署到测试环境，进行集成测试，跑自动化测试用例。
-
CD（Continuous Deploy），持续部署。代码测试通过后，能自动部署到类生产环境中进行集成测试，测试通过后再进行小流量的灰度验证，验证通过后代码就达到线上发布的要求了，就可以把代码自动部署到线上。
30讲如何做好微服务容量规划
容量规划系统的作用是根据各个微服务部署集群的最大容量和线上实际运行的负荷，来决定各个微服务是否需要弹性扩缩容，以及需要扩缩容多少台机器。
31讲微服务多机房部署实践
微服务多机房部署时要面临的三个问题，一是多机房访问时如何保证负载均衡，二是多机房之间的数据如何保证同步，三是多机房之间的数据如何保证一致性
32讲微服务混合云部署实践
混合云部署必须解决的三个问题：跨云服务的负载均衡、跨云服务的数据同步、跨云服务的容器运维
33讲下一代微服务架构ServiceMesh
Service Mesh是一种新型的用于处理服务与服务之间通信的技术，尤其适用以云原生应用形式部署的服务，能够保证服务与服务之间调用的可靠性。在实际部署时，Service Mesh通常以轻量级的网络代理的方式跟应用的代码部署在一起，从而以应用无感知的方式实现服务治理。
Service Mesh以轻量级的网络代理的方式与应用的代码部署在一起，用于保证服务与服务之间调用的可靠性，这与传统的微服务架构有着本质的区别
好处：
跨语言
轻量级（无SDK侵入）
第一代开源实现 Linkerd：
service mesh 实现原理
Service Mesh实现的关键就在于两点：一个是上面提到的轻量级的网络代理也叫SideCar，它的作用就是转发服务之间的调用；一个是基于SideCar的服务治理也被叫作Control Plane，它的作用是向SideCar发送各种指令，以完成各种服务治理功能。
a、Side Car
b、Control Plane
34讲Istio：ServiceMesh的代表产品
-
相比Linkerd，Istio引入了Control Plane的理念，通过Control Plane能带来强大的服务治理能力，可以称得上是Linkerd的进化，算是第二代的Service Mesh产品。
-
Istio默认的SideCar采用了Envoy，它是用C++语言实现的，在性能和资源消耗上要比采用Scala语言实现的Linkerd小，这一点对于延迟敏感型和资源敏感型的服务来说，尤其重要。
-
有Google和IBM的背书，尤其是在微服务容器化的大趋势下，云原生应用越来越受欢迎，而Google开源的Kubernetes可以说已经成为云原生应用默认采用的容器平台，基于此Google可以将Kubernetes与Istio很自然的整合，打造成云原生应用默认的服务治理方案。
