微服务架构

单体架构的困难和挑战

编译、部署困难

代码分支管理困难

因为单体应用非常庞大，所以代码模块也是由多个团队共同维护的。但最后还是要编译成一 个单体应用，统一发布。这就要求把各个团队的代码 merge 在一起，这个过程很容易发生 代码冲突。而 merge 的时候又是应用要发布的时候，发布过程本来就复杂，再加上代码 merge 带来的问题，各种情况纠缠在一起，极易出错。

数据库连接耗尽

对于一个巨型的应用而言，因为有大量的用户进行访问，所以必须把应用部署到大规模的服 务器集群上。然后每个应用都需要与数据库建立连接，大量的应用服务器连接到数据库，会 对数据库的连接产生巨大的压力，某些情况下甚至会耗尽数据库的连接。

新增业务困难

因为所有的业务都耦合在一个单一的大系统里，随着时间的发展，这个系统会变得非常的复 杂，想要维护这样一个系统是非常困难和复杂的。

发布困难

微服务框架原理

在面向服务的体系架构里面，服务提供者向注册中心注册自己的服务，而服务调用者到注册 中心去发现服务，发现服务以后，根据服务注册中心提供的访问接口和访问路径对服务发起 请求，由服务的提供者完成请求，返回结果给调用者。

微服务架构的落地实践

首先明确自己的需求：我们到底想用微服务达到什么样的目的？需求清晰了，再去考虑具体 要实现的价值，再根据价值构建我们的设计原则，根据原则寻找最佳实践，最后根据实践去 选择最合适的工具。

微服务间如何通讯

从通讯协议角度考虑

• Rest Api
• RPC
• MQ

从通讯模式角度考虑

如何选择 RPC框架

• I/O、线程调度模型
• 序列化方式
• 多语言支持

服务发现

客户端发现

服务端发现

服务编排

kubernetes

六边形表示的是 node节点，即 worker节点。每个工作节点上运行了kubelet服务以及 docker服务。 kubelet就相当于是该节点运行时的一个总管，他会管理这个当前 node上面运行的所有服务

deployment相当于是一个部署，圆圈相当于是一个 pod.pod是k8s概念中的最小单元

pod里边是容器。有独立的 ip地址。pod里面的容器可以共享网络以及存储的。

虚线表示 service,service也有自己独立的 ip。可对多个 pod进行负载均衡。使用 label selector来定义。

master虚线框代表的是 api server,他提供了资源操作的唯一入口，并且提供了认证、授权和访问控制。control manager负责维护集群的状态， scheduler负责资源调度。按照预定的调度策略。把 pod调度给相应的 node节点上，etcd主要用于一致性存储，保存了集群状态等等的信息。

kubelet负责维护当前节点上的容器的生命周期，也负责维护当前的节点的 volume和网络的管理。 kube-proxy负责 service提供内部的服务发现和负载均衡 kube-DNS负责整个集群的 DNS服务

dashboard提供一些集群相关的数据的展示和操作。

集群外要访问集群内部服务时，k8s可以把服务端口直接暴露在当前的 node上。直接访问 node的 ip就可以关联到这个端口

设计理念

• API设计原则（申明式）
• 控制机设计原则

网络

• CNI
• Flannel、Calico、Weave
• Pod网络

scheduler-preselect(预选规则)

• NodiskConflict(挂载冲突)
• CheckNodeMemoryPressure
• NodeSelector
• FitResource
• Affinity

scheduler-optimize-select(优选规则)

SelectorSpreadPriority LeastRequestedPriority AffinityPriority

pod通讯

• 同一个 pod内部通讯 用localhost地址访问彼此的端口。
• 同一个 node,不同 pod通讯 可通过 docker0网桥进行通讯，具体可通过访问pod的ip
• 不同 node，不同 pod通讯 通过 pod的 ip和 node的 ip关联

服务发现

• kube-proxy(ClusterIp)
• kube-proxy(NodePort)
• kube-DNS

CICD和 DevOps

持续集成 持续部署