架构之美【kubernetes、Prometheus、微服务、LVS负载均衡】

                                                kubernetes

       kubernetes，简称K8s，是用8代替8个字符“ubernete”而成的缩写。是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes提供了应用部署，规划，更新，维护的一种机制。 

传统的应用部署方式是通过插件或脚本来安装应用。这样做的缺点是应用的运行、配置、管理、所有生存周期将与当前操作系统绑定，这样做并不利于应用的升级更新/回滚等操作，当然也可以通过创建虚拟机的方式来实现某些功能，但是虚拟机非常重，并不利于可移植性。

新的方式是通过部署容器方式实现，每个容器之间互相隔离，每个容器有自己的文件系统 ，容器之间进程不会相互影响，能区分计算资源。相对于虚拟机，容器能快速部署，由于容器与底层设施、机器文件系统解耦的，所以它能在不同云、不同版本操作系统间进行迁移。

容器占用资源少、部署快，每个应用可以被打包成一个容器镜像，每个应用与容器间成一对一关系也使容器有更大优势，使用容器可以在build或release 的阶段，为应用创建容器镜像，因为每个应用不需要与其余的应用堆栈组合，也不依赖于生产环境基础结构，这使得从研发到测试、生产能提供一致环境。类似地，容器比虚拟机轻量、更“透明”，这更便于监控和管理。

Kubernetes概述

Kubernetes是Google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。

在Kubernetes中，我们可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要运维人员去进行复杂的手工配置和处理。

Kubernetes 特点

• 可移植: 支持公有云，私有云，混合云，多重云（multi-cloud）

• 可扩展: 模块化，插件化，可挂载，可组合

• 自动化: 自动部署，自动重启，自动复制，自动伸缩/扩展

Kubernetes节点

在这张系统架构图中，我们把服务分为运行在工作节点上的服务和组成集群级别控制板的服务。

Kubernetes节点有运行应用容器必备的服务，而这些都是受Master的控制。

每次个节点上当然都要运行Docker。Docker来负责所有具体的映像下载和容器运行。

Kubernetes主要由以下几个核心组件组成：

• etcd保存了整个集群的状态；
• apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
• controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
• scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
• kubelet负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；
• Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；
• kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；

除了核心组件，还有一些推荐的Add-ons：

• kube-dns负责为整个集群提供DNS服务
• Ingress Controller为服务提供外网入口
• Heapster提供资源监控
• Dashboard提供GUI
• Federation提供跨可用区的集群
• Fluentd-elasticsearch提供集群日志采集、存储与查询

 

分层架构

Kubernetes设计理念和功能其实就是一个类似Linux的分层架构，如下图所示

• 核心层：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境
• 应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）
• 管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）
• 接口层：kubectl命令行工具、客户端SDK以及集群联邦
• 生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴
  • Kubernetes外部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等
  • Kubernetes内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等

kubelet

kubelet负责管理pods和它们上面的容器，images镜像、volumes、etc。

kube-proxy

每一个节点也运行一个简单的网络代理和负载均衡（详见services FAQ )（PS:官方 英文）。 正如Kubernetes API里面定义的这些服务（详见the services doc）（PS:官方 英文）也可以在各种终端中以轮询的方式做一些简单的TCP和UDP传输。

服务端点目前是通过DNS或者环境变量( Docker-links-compatible 和 Kubernetes{FOO}_SERVICE_HOST 及 {FOO}_SERVICE_PORT 变量都支持)。这些变量由服务代理所管理的端口来解析。

Kubernetes控制面板

Kubernetes控制面板可以分为多个部分。目前它们都运行在一个master 节点，然而为了达到高可用性，这需要改变。不同部分一起协作提供一个统一的关于集群的视图。

etcd

所有master的持续状态都存在etcd的一个实例中。这可以很好地存储配置数据。因为有watch(观察者)的支持，各部件协调中的改变可以很快被察觉。

Kubernetes API Server

API服务提供Kubernetes API （PS:官方 英文）的服务。这个服务试图通过把所有或者大部分的业务逻辑放到不两只的部件中从而使其具有CRUD特性。它主要处理REST操作，在etcd中验证更新这些对象（并最终存储）。

Scheduler

调度器把未调度的pod通过binding api绑定到节点上。调度器是可插拔的，并且我们期待支持多集群的调度，未来甚至希望可以支持用户自定义的调度器。

Kubernetes控制管理服务器

所有其它的集群级别的功能目前都是由控制管理器所负责。例如，端点对象是被端点控制器来创建和更新。这些最终可以被分隔成不同的部件来让它们独自的可插拔。

replicationcontroller（PS:官方 英文）是一种建立于简单的 pod API之上的一种机制。一旦实现，我们最终计划把这变成一种通用的插件机制。

 

                                                       Prometheus

Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库(TSDB)。Prometheus使用Go语言开发，是Google BorgMon监控系统的开源版本。
2016年由Google发起Linux基金会旗下的原生云基金会(Cloud Native Computing Foundation), 将Prometheus纳入其下第二大开源项目。
Prometheus目前在开源社区相当活跃。
Prometheus和Heapster(Heapster是K8S的一个子项目，用于获取集群的性能数据。)相比功能更完善、更全面。Prometheus性能也足够支撑上万台规模的集群。

Prometheus的特点

• 多维度数据模型。
• 灵活的查询语言。
• 不依赖分布式存储，单个服务器节点是自主的。
• 通过基于HTTP的pull方式采集时序数据。
• 可以通过中间网关进行时序列数据推送。
• 通过服务发现或者静态配置来发现目标服务对象。
• 支持多种多样的图表和界面展示，比如Grafana等。

基本原理

Prometheus的基本原理是通过HTTP协议周期性抓取被监控组件的状态，任意组件只要提供对应的HTTP接口就可以接入监控。不需要任何SDK或者其他的集成过程。这样做非常适合做虚拟化环境监控系统，比如VM、Docker、Kubernetes等。输出被监控组件信息的HTTP接口被叫做exporter 。目前互联网公司常用的组件大部分都有exporter可以直接使用，比如Varnish、Haproxy、Nginx、MySQL、Linux系统信息(包括磁盘、内存、CPU、网络等等)。

服务过程

• Prometheus Daemon负责定时去目标上抓取metrics(指标)数据，每个抓取目标需要暴露一个http服务的接口给它定时抓取。Prometheus支持通过配置文件、文本文件、Zookeeper、Consul、DNS SRV Lookup等方式指定抓取目标。Prometheus采用PULL的方式进行监控，即服务器可以直接通过目标PULL数据或者间接地通过中间网关来Push数据。
• Prometheus在本地存储抓取的所有数据，并通过一定规则进行清理和整理数据，并把得到的结果存储到新的时间序列中。
• Prometheus通过PromQL和其他API可视化地展示收集的数据。Prometheus支持很多方式的图表可视化，例如Grafana、自带的Promdash以及自身提供的模版引擎等等。Prometheus还提供HTTP API的查询方式，自定义所需要的输出。
• PushGateway支持Client主动推送metrics到PushGateway，而Prometheus只是定时去Gateway上抓取数据。
• Alertmanager是独立于Prometheus的一个组件，可以支持Prometheus的查询语句，提供十分灵活的报警方式。

三大套件

• Server 主要负责数据采集和存储，提供PromQL查询语言的支持。
• Alertmanager 警告管理器，用来进行报警。
• Push Gateway 支持临时性Job主动推送指标的中间网关。

 

                                                         微服务

传统的it架构的缺陷：

使用传统的整体式架构(Monolithic Architecture)应用开发系统，如CRM、ERP等大型应用，随着新需求的不断增加，企业更新和修复大型整体式应用变得越来越困难；

随着移动互联网的发展，企业被迫将其应用迁移至现代化UI界面架构以便能兼容移动设备，这要求企业能实现应用功能的快速上线；

许多企业在SOA投资中得到的回报有限，SOA可以通过标准化服务接口实现能力的重用，但对于快速变化的需求，受到整体式应用的限制，有时候显得力不从心；

二、什么是微服务？

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。

 

1.1 产品现状

1、各产品系统独立开发，代码复用率低，系统之间互相调用，耦合严重，系统解耦独立部署困难。
2、传统的单体架构，规模越来越大也越来越笨重；当新功能的开发、功能的重构变得不再敏捷可控；测试者的回归测试边界难以琢磨；系统的上线部署也变的艰难
3、高并发访问下无法提供可靠性服务
4、持续集成、持续部署、持续交付等工程效率化工具严重缺失
5、监控系统、日志分析等系统稳定性工具严重缺失
以上种种情况，都让我们应对需求的变化而变得迟钝。

1.2 业务需求

架构肯定是为业务需求而生的，先来看看我们面对的业务需求及其特点。平台最主要满足两大类业务需求：面向餐饮企业在餐饮新零售下的经营和运营需求和面向产品及运营团队。
具体来看：
1、餐饮新零售下的餐饮企业经营和运营的痛点

• 如何提升营销能力和管理会员，以更低的成本为餐饮企业带来更多利润

• 如何对数据进行深度挖掘和分析，助力决策者进行运营决策

• 如何掌握实时数据，让决策者及时了解餐厅运营情况

2、面向产品及运营团队

• 主要是提升产品控制能力，促进整体系统的良好运转

因此开发SAAS服务的产品迫在眉睫，需要满足快速开发、灵活升级、高性能、高可用、高稳定、简化运维等更高的需求。

这一步的转型，不是"快"与"慢"，而是"生"与"死"。

二、微服务概念

专注于单一责任与功能独立运行的服务，模组化方式组合出大型应用。

2.1 特点

• 集中式架构：单体无分散

• 分布式架构：分散压力

• 微服务架构：分散能力

2.2 微服务架构优势

• 每个微服务组件都是简单灵活的，能够独立部署。不再像单体应用时代，应用需要一个庞大的应用服务器来支撑。

• 可以由一个小团队负责更专注专业，相应的也就更高效可靠。

• 微服务之间是松耦合的，微服务内部是高内聚的，每个微服务很容易按需扩展。

三、微服务技术选型和微服务的问题

3.1 技术选型

3.1.1 技术矩阵结论

• Netflix提供了比较全面的解决方案

• Spring Cloud对于Netflix的封装比较全面

• Spring Cloud基于Spring Boot，团队有基础

• Spring Cloud提供了Control Bus能够帮助实现监控埋点

• 业务应用部署在阿里云，Spring Cloud对12 Factors以及Cloud-Native的支持，有利于在云环境下使用

3.1.2 团队期望

• 首先支持Rest

• 团队技术栈和实例比较单薄，希望对新的技术平滑的学习曲线和能够Hold住

• 小团队，希望能够有一个比较全面的解决方案

• 目前团队主要采用Spring Cloud + Spring Boot的方式实现服务化

有关技术选型详细分析，请查看我的上一篇文章《我的技术选型》。

3.2 微服务带来的问题

• 依赖服务变更很难跟踪，其他团队的服务接口文档过期怎么办？依赖的服务没有准备好，如何验证我开发的功能。

• 部分模块重复构建，跨团队、跨系统、跨语言会有很多的重复建设。

• 微服务放大了分布式架构的系列问题，如分布式事务怎么处理？依赖服务不稳定怎么办？

• 运维复杂度陡增，如：部署物数量多、监控进程多导致整体运维复杂度提升。

上面这些问题我们应该都遇到过，并且总结形成了自己的一些解决方案，比如提供文档管理、服务治理、服务模拟的工具和框架； 实现统一认证、统一配置、统一日志框架、分布式汇总分析； 采用全局事务方案、采用异步模拟同步；搭建持续集成平台、统一监控平台等等。

微服务架构是一把双刃剑，虽然解决了集中式架构和分布式架构的问题，却带来了如上种种问题。因此我们是需要一个微服务应用平台才能整体性的解决这些问题。

四、微服务架构设计

4.1 微服务应用架构设计原则

4.2 微服务应用架构设计目标

微服务架构设计的目标，满足快速开发、灵活升级、高性能、高可用、高稳定、简化运维等更高的需求。

4.3 微服务应用总体架构

微服务应用平台的总体架构，主要是从开发集成、微服务运行容器与平台、运行时监控治理和外部渠道接入等维度来划分和考虑的。

• 开发集成：主要是搭建一个微服务平台需要具备的一些工具和仓库

• 运行时：要有微服务平台来提供一些基础能力和分布式的支撑能力，我们的微服务运行容器则会运行在这个平台之上。

• 监控治理：则是致力于在运行时能够对受管的微服务进行统一的监控、配置等能力。

• 服务网关： 则是负责与前端的WEB应用 移动APP 等渠道集成，对前端请求进行认证鉴权，然后路由转发。

4.4 微服务框架概览

 

这里不详细讲解服务框架中每一个组件，另开一篇文章来讲解。

五、微服务架构设计落地

5.1 基础环境

一个企业的IT建设非常重要的三大基础环境：团队协作环境、服务基础环境、IT基础设施。

• 团队协作环境：主要是DevOps领域的范畴，负责从需求到计划任务，团队协作，再到质量管理、持续集成和发布。

• 服务基础环境：指的是微服务应用平台，其目标主要就是要支撑微服务应用的设计开发测试，运行期的业务数据处理和应用的管理监控。

• IT基础设施：主要是各种运行环境支撑如IaaS (VM虚拟化)和CaaS (容器虚拟化)等实现方式。

5.2 服务通信

 

 

服务间的通信，往往采用HTTP+REST 和 RPC通信协议。

 

HTTP+REST，对服务约束完全靠提供者的自觉。

• 特点是简单，对开发使用友好。

• 缺点治理起来困难，连接的无状态，缺失多路复用、服务端推送等。

 

RPC对通信双方定义了数据约束。

• 连接大多基于长连接以获得性能的提升及附带的服务端推、调用链路监控埋点等，增强了系统的附加能力。

• 缺点是对调用端提出了新的要求。

综合来看，RPC从性能、契约优先来说具有优势，如何做到扬长避短呢？
引入GateWay层，让REST与RPC的优点进行融合，在GateWay层提供REST的接入能力。

5.3 服务注册/发现

以前的单体应用之间互相调用时配置个IP或域名就行了，但在微服务架构下，服务提供者会有很多，手工配置IP地址或域名又变成了一个耦合和繁琐的事情。那么服务自动注册发现的方案就解决了这个问题。
我们的服务注册发现能力是依赖SpringCloud Eureka组件实现的。服务在启动的时候，会将自己要发布的服务注册到服务注册中心；运行时，如果需要调用其他微服务的接口，那么就要先到注册中心获取服务提供者的地址，拿到地址后，通过微服务容器内部的简单负载均衡期进行路由用。

Eureka Server特点：

• Eureka Client会缓存服务注册信息

• Eureka Server的注册信息只存储在内存中

• Eureka的注册只针对application级别，不支持更细粒度的服务注册，如单个服务Rest

• 服务每隔30秒向Eureka Server发送心跳，不建议修改心跳时间。Eureka用这个时间来判断集群内是否存在大范围的服务通信异常

• 如果在15分钟内有85%的服务没有被续约，则Eureka Server停止移除已注册的服务，以保障已注册的服务信息不丢失

• Eureka Server之间的数据同步，采用全量拉取，增量同步的方式

• Eureka 满足分布式事务中的CAP理论中的AP

5.4 集中式配置管理

微服务分布式环境下，一个系统拆分为很多个微服务，一定要告别运维手工修改配置配置的方式。需要采用集中配置管理的方式来提升运维的效率。
配置文件主要有运行前的静态配置和运行期的动态配置两种。

• 静态配置通常是在编译部署包之前设置好。

• 动态配置则是系统运行过程中需要调整的系统变量或者业务参数。

 

要想做到集中的配置管理，那么需要注意以下几点。

• 配置与介质分离，这个就需要通过制定规范的方式来控制。

• 配置的方式要统一，格式、读写方式、变更热更新的模式尽量统一，要采用统一的配置框架。

• 需要运行时需要有个配置中心来统一管理业务系统中的配置信息。

概念抽象：
介质，是源码编译后的产物与环境无关，多环境下应该是可以共用的如：jar

5.5 统一认证鉴权

安全认证方面，我们基于Spring Security OAuth2 + JWT做安全令牌，实现统一的安全认证与鉴权，使得微服务之间能够按需隔离和安全互通。
认证鉴权一定是个公共的服务，而不是多个系统各自建设。

5.6 分布式调用

微服务架构下，相对于传统部署方式，存在更多的分布式调用，那么“如何在不确定的环境中交付确定的服务”，这句话可以简单理解为，我所依赖的服务的可靠性是无法保证的情况下，我如何保证自己能够正常的提供服务，不被我依赖的其他服务拖垮？
我们采用的方案：

• 合理的超时时间

• 合理的重试机制

• 合理的异步机制

• 合理的限流机制（调用次数和频率）

• 合理的降级机制

• 合理的熔断机制

推荐SEDA架构来解决这个问题。
SEDA : staged event-driven architecture本质上就是采用分布式事件驱动的模式，用异步模拟来同步，无阻塞等待，再加上资源分配隔离结起来的一个解决方案。

5.7 分布式事务

分布式事务-CAP

• C 分布式环境下多个节点的数据是否强一致

• A 分布式服务能一直保证可用状态

• P 网络分区的容错性

分布式事务-策略

• 避免跨库事务，尽可能相关表在同一个DB

• 2PC 3PC TCC 补偿模式等， 耗时且复杂

• 基于MQ的最终一致性 简单、高效、易于理解

• 将远程分布式事务拆解成一系列本地的事务

分布式事务-基于MQ

5.8 服务拆分

服务拆分方式

AKF扩展立方体，是抽象总结的应用扩展的三个维度。

• X轴 扩展部署实例，就是讲单体系统多运行几个实例，做个集群加负载均衡的模式。

• Y轴 业务领域分离，就是基于不同的业务拆分。

• Z轴 数据隔离分区，比如共享单车在用户量激增时，集群模式撑不住了，那就按照用户请求的地区进行数据分区，北京、上海、深圳等多建几个集群。

 

服务拆分要点

• 低耦合、高内聚：一个服务完成一个独立的功能

• 按照团队结构：小规模团队维护，快速迭代

5.9 数据库拆分

单库单表难以支撑日益增长的业务量和数据量，服务拆分了数据库也跟着拆分。

5.9.1 模式

• 垂直拆分

• 水平拆分

 

5.9.2 原则

• 尽可能不拆分

• 避免跨库事务

• 单表量级1000w

• 避免垮裤join（冗余、全局表）

   

 

 

5.10 日志管理

日志主要有三种，系统日志，业务日志，跟踪日志。有了这些日志，在出问题的时候能够帮助我们获取一些关键信息进行问题定位。
要想做到，出了问题能够追根溯源，那么我们需要一个可以将整个完整的请求调用链串联起来的标识，这个标识能够让我们快速定位问题发生的具体时间地点以及相关信息，能够快速还原业务交易全链路。对这些日志与流水的细节处理，对于系统运维问题定位有非常大的帮助。通常开源框架只是提供基础的框架，而设计一个平台则一定要考虑直接提供统一规范的基础能力。

分布式跟踪

5.11 服务契约与API管理

对于前面提到的微服务带来的依赖管理问题，我们需要提供API管理能力。说到API管理，那首先就用提到服务契约。
服务契约，主要描述服务接口的输入输出规格标准和其他一些服务调用集成相关的规格内容。

5.12 服务契约与服务模拟

有了服务契约，研发人员就可以方便的获取到依赖服务变更的情况，能够及时的根据依赖服务的变化调整自己的程序，并且能够方便的进行模拟测试验证。
根据契约生成模拟服务也就是我们常说的服务挡板，这样即使依赖的其他服务还无法提供功能，我们也可以通过挡板来进行联调测试。

5.13 微服务容器

我们要做稳定、高效、易扩展的微服务应用，实际上我们需要做的事情还是非常多的。如果没有一个统一的微服务容器，这些能力在每个微服务组件中都需要建设一遍，也很难集成到一起。有了统一的微服务运行容器和一些公共的基础服务，前面所提到的微服务架构下部分组件重复建设的问题也迎刃而解。

5.14 持续集成与持续部署

在运维方面，首先我们要解决的就是持续集成和持续交付，能够方便的用持续集成环境把程序编译成介质包和部署包并持续稳定的部署到每个环境。
概念抽象：
介质：是源码编译后的产物与环境无关，多环境下应该是可以共用的。如：jar
配置：则是环境相关的信息。
部署包=配置+介质。

5.15 微服务平台与容器云、DevOps的关系

就微服务应用平台本身来说，并不依赖DevOps和容器云，开发好的部署包可以运行在物理机、虚拟机或者是容器中。然而当微服务应用平台结合了DevOps和容器云之后，我们就会发现，持续集成和交付变成了一个非常简单便捷并且又可靠的过程。简单几步操作，整套开发、测试、预发或者生产环境就能够搭建完成。
整个过程的复杂度都由平台给屏蔽掉了，通过三大基础环境的整合，我们能够使分散的微服务组件更简单方便的进行统一管理和运维交付。

5.16 技术团队的组织

技术团队组织 – 小团队

根据“康威定律”，软件架构是由组织的架构决定的，因此按照贝索斯“two-pizza”团队的理论和敏捷方法，构建小的团队，可以有效减少沟通成本，有利于团队的自治。
我们通过让一个小的团队有比较全面的建制，Leader（熟悉业务和技术）+ 前端工程师 + 后端工程师，往往可以能够比较独立地承接一个或者几个业务的工作。这样团队成员整体负责一个或者几个业务模块，可以极大地提高团队成员的参与感、使命感和责任感，团队成员相互帮助，高度自治，大家要么一起成功，要么一起失败。

技术团队组织 – 团队划分

团队的划分，是按照业务线划分的。随着业务的复杂度的增加，可以按照业务/子业务线的方式来划分团队，但并不是绝对的扁平化，而是严格遵循two-pizza原则。
业务线的划分常常按业务细分，技术团队要负责支持全部业务线，因此技术团队的划分通常按系统或者是业务，Two pizza团队的原则在组织层级的任何部分都适用，当人数过多时，必须继续拆分。

技术团队组织 – 团队合作

技术团队组织 – 结果导向

1. 主人翁意识（Ownership）

2. 行动力（Bias for Action）

3. 吃自己的狗粮（Eat your dog food）
   • 工程师负责从需求调研、设计、开发、测试、部署、维护、监控、功能升级等一系列的工作，也就是说软件工程师负责应用或者服务的全生命周期的所有工作
   • 运维是团队成员的第一要务，在强大的自动化运维工具的支撑下，软件工程师必须负责服务或者应用的SLA

4. 开发人员参与架构设计，而不是架构师参与开发
   • 研发人员是Owner，对业务和团队负责
   • 强调抽象和简化，将复杂的问题分解成简单的问题，并有效解决，避免过度设计
   • 鼓励用新技术解决问题，但强调掌控力

六、微服务架构设计过程中积累的心得

• 深入理解业务

• 设计阶段要追求完美，实践阶段要考虑实际情况作出平衡

• 容错能力

• 监控先行

• 任何上线可回滚

七、总结

微服务架构是技术升级，但更多的是管理模式的升级、思维方式的转变。

 

               

                  LVS负载均衡（LVS简介、三种工作模式、十种调度算法）

一、LVS简介

       LVS（Linux Virtual Server）即Linux虚拟服务器，是由章文嵩博士主导的开源负载均衡项目，目前LVS已经被集成到Linux内核模块中。该项目在Linux内核中实现了基于IP的数据请求负载均衡调度方案，其体系结构如图1所示，终端互联网用户从外部访问公司的外部负载均衡服务器，终端用户的Web请求会发送给LVS调度器，调度器根据自己预设的算法决定将该请求发送给后端的某台Web服务器，比如，轮询算法可以将外部的请求平均分发给后端的所有服务器，终端用户访问LVS调度器虽然会被转发到后端真实的服务器，但如果真实服务器连接的是相同的存储，提供的服务也是相同的服务，最终用户不管是访问哪台真实服务器，得到的服务内容都是一样的，整个集群对用户而言都是透明的。最后根据LVS工作模式的不同，真实服务器会选择不同的方式将用户需要的数据发送到终端用户，LVS工作模式分为NAT模式、TUN模式、以及DR模式。

二、三种工作模式的解析。

1、基于NAT的LVS模式负载均衡

      NAT（Network Address Translation）即网络地址转换，其作用是通过数据报头的修改，使得位于企业内部的私有IP地址可以访问外网，以及外部用用户可以访问位于公司内部的私有IP主机。VS/NAT工作模式拓扑结构如图2所示，LVS负载调度器可以使用两块网卡配置不同的IP地址，eth0设置为私钥IP与内部网络通过交换设备相互连接，eth1设备为外网IP与外部网络联通。

       第一步，用户通过互联网DNS服务器解析到公司负载均衡设备上面的外网地址，相对于真实服务器而言，LVS外网IP又称VIP（Virtual IP Address），用户通过访问VIP，即可连接后端的真实服务器（Real Server），而这一切对用户而言都是透明的，用户以为自己访问的就是真实服务器，但他并不知道自己访问的VIP仅仅是一个调度器，也不清楚后端的真实服务器到底在哪里、有多少真实服务器。

   第二步，用户将请求发送至124.126.147.168，此时LVS将根据预设的算法选择后端的一台真实服务器（192.168.0.1~192.168.0.3），将数据请求包转发给真实服务器，并且在转发之前LVS会修改数据包中的目标地址以及目标端口，目标地址与目标端口将被修改为选出的真实服务器IP地址以及相应的端口。

    第三步，真实的服务器将响应数据包返回给LVS调度器，调度器在得到响应的数据包后会将源地址和源端口修改为VIP及调度器相应的端口，修改完成后，由调度器将响应数据包发送回终端用户，另外，由于LVS调度器有一个连接Hash表，该表中会记录连接请求及转发信息，当同一个连接的下一个数据包发送给调度器时，从该Hash表中可以直接找到之前的连接记录，并根据记录信息选出相同的真实服务器及端口信息。

2、基于TUN的LVS负载均衡

       在LVS（NAT）模式的集群环境中，由于所有的数据请求及响应的数据包都需要经过LVS调度器转发，如果后端服务器的数量大于10台，则调度器就会成为整个集群环境的瓶颈。我们知道，数据请求包往往远小于响应数据包的大小。因为响应数据包中包含有客户需要的具体数据，所以LVS（TUN）的思路就是将请求与响应数据分离，让调度器仅处理数据请求，而让真实服务器响应数据包直接返回给客户端。VS/TUN工作模式拓扑结构如图3所示。其中，IP隧道（IP tunning）是一种数据包封装技术，它可以将原始数据包封装并添加新的包头（内容包括新的源地址及端口、目标地址及端口），从而实现将一个目标为调度器的VIP地址的数据包封装，通过隧道转发给后端的真实服务器（Real Server），通过将客户端发往调度器的原始数据包封装，并在其基础上添加新的数据包头（修改目标地址为调度器选择出来的真实服务器的IP地址及对应端口），LVS（TUN）模式要求真实服务器可以直接与外部网络连接，真实服务器在收到请求数据包后直接给客户端主机响应数据。

3、基于DR的LVS负载均衡

在LVS（TUN）模式下，由于需要在LVS调度器与真实服务器之间创建隧道连接，这同样会增加服务器的负担。与LVS（TUN）类似，DR模式也叫直接路由模式，其体系结构如图4所示，该模式中LVS依然仅承担数据的入站请求以及根据算法选出合理的真实服务器，最终由后端真实服务器负责将响应数据包发送返回给客户端。与隧道模式不同的是，直接路由模式（DR模式）要求调度器与后端服务器必须在同一个局域网内，VIP地址需要在调度器与后端所有的服务器间共享，因为最终的真实服务器给客户端回应数据包时需要设置源IP为VIP地址，目标IP为客户端IP，这样客户端访问的是调度器的VIP地址，回应的源地址也依然是该VIP地址（真实服务器上的VIP），客户端是感觉不到后端服务器存在的。由于多台计算机都设置了同样一个VIP地址，所以在直接路由模式中要求调度器的VIP地址是对外可见的，客户端需要将请求数据包发送到调度器主机，而所有的真实服务器的VIP地址必须配置在Non-ARP的网络设备上，也就是该网络设备并不会向外广播自己的MAC及对应的IP地址，真实服务器的VIP对外界是不可见的，但真实服务器却可以接受目标地址VIP的网络请求，并在回应数据包时将源地址设置为该VIP地址。调度器根据算法在选出真实服务器后，在不修改数据报文的情况下，将数据帧的MAC地址修改为选出的真实服务器的MAC地址，通过交换机将该数据帧发给真实服务器。整个过程中，真实服务器的VIP不需要对外界可见。

三、LVS负载均衡调度算法

      根据前面的介绍，我们了解了LVS的三种工作模式，但不管实际环境中采用的是哪种模式，调度算法进行调度的策略与算法都是LVS的核心技术，LVS在内核中主要实现了一下十种调度算法。

1.轮询调度

轮询调度（Round Robin 简称'RR'）算法就是按依次循环的方式将请求调度到不同的服务器上，该算法最大的特点就是实现简单。轮询算法假设所有的服务器处理请求的能力都一样的，调度器会将所有的请求平均分配给每个真实服务器。

2.加权轮询调度

加权轮询（Weight Round Robin 简称'WRR'）算法主要是对轮询算法的一种优化与补充，LVS会考虑每台服务器的性能，并给每台服务器添加一个权值，如果服务器A的权值为1，服务器B的权值为2，则调度器调度到服务器B的请求会是服务器A的两倍。权值越高的服务器，处理的请求越多。

3.最小连接调度

最小连接调度（Least Connections 简称'LC'）算法是把新的连接请求分配到当前连接数最小的服务器。最小连接调度是一种动态的调度算法，它通过服务器当前活跃的连接数来估计服务器的情况。调度器需要记录各个服务器已建立连接的数目，当一个请求被调度到某台服务器，其连接数加1；当连接中断或者超时，其连接数减1。

（集群系统的真实服务器具有相近的系统性能，采用最小连接调度算法可以比较好地均衡负载。)

4.加权最小连接调度

加权最少连接（Weight Least Connections 简称'WLC'）算法是最小连接调度的超集，各个服务器相应的权值表示其处理性能。服务器的缺省权值为1，系统管理员可以动态地设置服务器的权值。加权最小连接调度在调度新连接时尽可能使服务器的已建立连接数和其权值成比例。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。

5.基于局部的最少连接

基于局部的最少连接调度（Locality-Based Least Connections 简称'LBLC'）算法是针对请求报文的目标IP地址的 负载均衡调度，目前主要用于Cache集群系统，因为在Cache集群客户请求报文的目标IP地址是变化的。这里假设任何后端服务器都可以处理任一请求，算法的设计目标是在服务器的负载基本平衡情况下，将相同目标IP地址的请求调度到同一台服务器，来提高各台服务器的访问局部性和Cache命中率，从而提升整个集群系统的处理能力。LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则使用'最少连接'的原则选出一个可用的服务器，将请求发送到服务器。

6.带复制的基于局部性的最少连接

带复制的基于局部性的最少连接（Locality-Based Least Connections with Replication  简称'LBLCR'）算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统，它与LBLC算法不同之处是它要维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。按'最小连接'原则从该服务器组中选出一一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按'最小连接'原则从整个集群中选出一台服务器，将该服务器加入到这个服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。

7.目标地址散列调度

目标地址散列调度（Destination Hashing 简称'DH'）算法先根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且并未超载，将请求发送到该服务器，否则返回空。

8.源地址散列调度U

源地址散列调度（Source Hashing  简称'SH'）算法先根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且并未超载，将请求发送到该服务器，否则返回空。它采用的散列函数与目标地址散列调度算法的相同，它的算法流程与目标地址散列调度算法的基本相似。

9.最短的期望的延迟

最短的期望的延迟调度（Shortest Expected Delay 简称'SED'）算法基于WLC算法。举个例子吧，ABC三台服务器的权重分别为1、2、3 。那么如果使用WLC算法的话一个新请求进入时它可能会分给ABC中的任意一个。使用SED算法后会进行一个运算

A：（1+1）/1=2   B：（1+2）/2=3/2   C：（1+3）/3=4/3   就把请求交给得出运算结果最小的服务器。

10.最少队列调度

最少队列调度（Never Queue 简称'NQ'）算法，无需队列。如果有realserver的连接数等于0就直接分配过去，不需要在进行SED运算。