上期回顾
在上一期的专栏中，我们详细阐述了SmartOps混合云管理平台如何从微服务架构演进到云原生架构，并且展示了流量与安全管控的全景架构。在本期文章中，我们将继续分享SmartOps在云原生架构、可观测性建设方面的迭代与升级。
五、基于云原生架构的SmartOps
在微服务架构中，API网关负责各类应用请求路由、API组合和协议转换，同时一些API网关也负责验证、鉴权、负载均衡、协议转换、数据缓存等，其中框架网关有Netflix Zuul、Spring Cloud Gateway，云原生网关有Ingress-Treafik/Nginx/APISIX、Kong、Istio、Linkerd等。在SmartOps微服务架构中采用Spring Cloud Gateway作为API网关方案，部分认证鉴权使用Spring Cloud Gateway完成，因此需配合云上LB进行流量接入。
通过使用LB + NodePort + Spring Gateway方案，结合公有云七层负载均衡，可以实现一个域名端口对应多个 Service，如图可以根据 path 路径，/cmp 对应 NodePort 的 32111，/gateway 对应 NodePort 的 32000 端口，不仅可以实现高可用还可以实现SSL卸载。
LB：使用公有云的七层负载均衡可以实现根据域名流量转发和负载均衡，与SSL的卸载功能；
NodePort：利用TKE负载均衡的NodePort实现从LB流量转发到K8s集群内部，实现流量接入；
Spring Gateway：使用Spring Gateway作为API网关入口，进行认证和鉴权及南北流量服务请求的转发。
我们针对SmartOps服务注册发现中心进行演进升级，由原始Spring Cloud Consul方式演进为Spring Cloud Kubernetes方式，并直接利用Kubernetes内部服务注册发现底层能力。
在微服务架构中，由于服务众多且单个服务具有多个实例同时部署在Kubernetes集群中，实例的IP地址是可能随时变化的，需针对该情况对服务调用进行集中统一管理，因此我们引入服务注册发现机制。
服务注册和发现的意思是指服务进程在注册中心注册自己的位置，客户端应用进程向注册中心发起查询来获取服务的位置，服务发现的一个重要作用就是提供一个可用的服务列表。通过统一集中化管理使得服务直接仅通过服务名称即可调用，无需知道具体实例的IP地址。
在Spring Cloud Consul服务注册发现方案中，各微服务注册到Consul Server上，服务间调用从Consul获取其他应用信息实现服务发现，在客户端发起对目标端请求中，客户端使用包括Ribbon和Spring Cloud LoadBalancer等实现负载均衡：
使用方式比较简单，引入依赖及配置相关信息：
引入依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-consul-discovery</artifactId>
</dependency>
配置Consul信息：
Consul配置
server:
port: 8206
spring:
application:
name: consul-user-service
cloud:
consul: #Consul服务注册发现配置
host: localhost
port: 8500
discovery:
service-name: ${spring.application.name}
在该架构中，业务遇到过以下挑战：
1.Consul Cluster需要采用高可用部署，该组建需要投入额外成本进行维护。
利用云原生实现服务注册发现，需先理解Kubernetes中Service自动注册DNS过程：
1. 向API Server 用 POST 方式提交一个新的Service 定义；
2. 这个请求需要经过认证、鉴权以及其它的准入策略检查之后才会放行；
3. Service 得到一个 ClusterIP（虚拟 IP 地址）并保存到集群数据仓库；
4. 在集群范围内传播 Service 配置；
5. 集群DNS 服务得知该 Service 的创建，据此创建必要的DNS A 记录。
总体来说，Kubernetes的服务注册与发现主要通过Etcd+CoreDNS来实现，其中又包含了endpoints/kube-proxy等组件的协同。
方案简介：使用 K8s 原生Service/Endpoints/Coredns/Etcd等内置资源对象和相关服务组建实现服务注册发现过程，服务注册和服务发现均通过内置Service对象完成，借助K8s Service的负载均衡能力可减少额外部署和维护服务注册发现中心成本，针对高级流量治理功能需要借助其他服务治理框架实现。
服务注册：Spring Boot 应用配置提供service服务，启动后k8s集群针对调用该service，后端会返回具体的pod列表。
服务发现：在同一名称空间，直接使用service信息发起调用。
方案特点：
优势：负载均衡算法在服务端实现（service 的原生负载均衡算法），后期可使用服务治理框架，例如istio/linkerd进行服务治理。
不足：服务直接通过k8s服务发现，经过service一层在宿主机请求通过iptables/ipvs转发一层，性能稍弱。
Spring Cloud Kubernetes 服务注册发现：
服务注册通过Spring Cloud应用的service资源对象进行注册，服务发现通过项目引入Spring-cloud-kubernetes-discovery的jar包，利用Kubernetes-client与API-server进行Rest调用获取Service后端关联的Endpoints信息，通过spring cloud openFeign完成服务间的通信，Spring Cloud ribbon实现负载均衡。采用如上几个模块，可以在k8s的环境下实现重试、超时、限流、负载均衡等常用功能。
Spring Cloud Kubernetes 服务注册发现-东西流量：
方案简介：使用Kubernetes原生service/endpoints/coredns/etcd组建实现服务注册过程，服务发现通过Spring Cloud Kubernetes调用Kubernetes API-server获取后端服务Pod的IP/Port，利用openFeign完成服务间调用并且利用ribbon可实现客户端负载均衡。
服务注册：Spring Cloud应用配置有service的服务，启动后k8s集群针对调用该service，后端会返回具体的pod列表。
服务发现：通过Spring Cloud Kubernetes调用Kubernetes API-server获取后端服务Pod的IP/Port。
方案特点：
优势：服务直接通过k8s服务发现，获取service后的实例POD IP和端口，流量直接对POD发起，不经过service转发，性能高；
不足：负载均衡在调用端(客户端)实现，例如ribbon，后期服务治理框架如Istio/Linkerd可能需改造。
Spring Cloud Kubernetes 服务注册发现-南北流量：
方案简介：使用Kubernetes原生service/endpoints/
coredns/etcd组建实现服务注册过程，Springboot Gateway 使用Spring Cloud Kubernetes 与api Server的http交互，获取后端 服务 Services / Endpoints，完成服务请求转发。
服务注册：Spring Cloud应用配置有service的服务，启动后k8s集群针对调用该service，后端会返回具体的pod列表。
服务发现：服务发现通过Spring Cloud Kubernetes调用Kubernetes API-server获取后端服务Pod的IP/Port，Gateway进行请求转发。
方案特点：
优势：Gateway服务通过k8s服务发现，获取service后的实例POD IP和PORT，从而发起针对POD调用，该请求不经过Service转发，性能较高；
不足：负载均衡在调用端(客户端)实现，例如ribbon，后期服务治理框架如Istio/Linkerd可能需改造。
传统的静态配置方式要想修改某个配置只能修改之后重新发布应用。如实现动态性，可以选择使用数据库通过定时轮询访问数据库来感知配置的变化。轮询频率低感知配置变化的延时长，轮询频率高感知配置变化的延时短，比较损耗性能，需要在实时性和性能之间做折中。配置中心专门针对这个业务场景，兼顾实时性和一致性来管理动态配置。
SmartOps原始配置中心为Spring Cloud Config方案，需要考虑以下问题：
需要独立在K8s中部署Config服务；
需要考虑Config服务的高可用性；
由于Config服务需要链接私网git repo，需考虑安全问题与网络互通问题。
以下列出了一些其他配置中心的功能点对比：
演进方向：由于业务在Kubernetes上，所以应尽可能利用K8s原生配置管理能力，将配置中心不可控性托付给K8s，使用K8s原生configmap和secret资源无需考虑单独部署配置中心，不用引入新服务。如果configmap/secret发生变更，服务能及时监控到这一变化从而按照配置更新策略进行动态更新或者服务重启，如下选用Spring Cloud Kubernetes配置中心示意图：
Spring Cloud Kubernetes 配置中心方案简介：spring-cloud-starter-kubernetes-config是spring-cloud-starter-kubernetes下的一个库，作用是将kubernetes的configmap与SpringCloud Config结合起来。Spring-boot-actuator/spring-boot-actuator-autoconfigure 两个包的引入，使得应用可以进行热更新，当configmap/secret发生变更的时候，可以不重启Pod或进程进行热变更配置。
方案特点：
优势：使用K8s内置配置资源，无需再次引入第三次配置中心服务，也不用考虑引入的配置中心服务高可用部署，在云原生架构架构中，配置中心下沉至基础设施层，既解耦配置与代码还极大的减少了配置服务本身的维护成本。
不足：dev/test 环境也需要上K8s，为了确保环境一致性， 需要将配置资源configmap/secret引入到GitOps流程中。
利用云原生配置管理，安全性问题Secret存储了相对敏感的信息，需结合其他工具或解决方案解决，例如后期可以配合Vault 或者Sealed Secrets解决K8s配置安全性问题，针对热更新可利用reloader或其他方案解决。
在平台中存在大量定时任务，而且很多服务任务实现方式不一致，一旦遇到问题排错成本高、很难统一管控。针对此困境，我们需进行集中化分布式任务调度平台改造，选用轻量级xxl-job中心式的调度平台，不仅开箱即用，而且操作简易、上手快，与SpringBoot有非常好的集成且监控界面就集成在调度中心、界面也非常简洁。选取xxl-job做调度平台，承担的调度中心职责有：1）负责管理调度信息，按照调度配置发出调度请求，自身不承担业务代码。2）支持可视化界面，可以在调度中心对任务进行新增、更新、删除，会实时生效。3）支持监控调度结果，查看执行日志，查看调度任务统计报表，任务失败告警等等。4）执行器：负责接收调度请求，执行调度任务的业务逻辑。执行器启动后需要注册到调度中心，接收调度中心发出的执行请求、终止请求、日志请求等等。
同一个服务多个实例的任务存在互斥时，需要统一的调度；
任务调度需要支持高可用、监控、故障告警；
需要统一管理和追踪各个服务节点任务调度的结果，需要记录保存任务属性信息等。
利用其高可用部署在Kubernetes集群中，实现分布式任务调度集中管控，可大幅降低开发成本并且提升研发效能，极大程度解决后台任务难管控的问题。
之前SmartOps采用Graylog 日志监控方案，在代码内部引入日志采集jar包，将日志数据收集在graylog server端。目前graylog server部署在K8s集群内，而Graylog server使用MongoDB和ES，由于ES和MongoDB占用K8s集群资源，这存在一定问题，本次改造目标为：
日志服务下沉到基础设施层与业务低耦合，业务人员仅需关注自身业务；
日志服务无侵入业务代码；
开发服务适配多语言；
不占用过多K8s资源；
打造易维护、扩展性更强的日志监控方案。
业务日志遵循一定规范，如将日志输出到stdout/stderr，在Node上以Ds方式部署日志采集Pod，针对打印到控制台日志进行查看分析。
分布式链路使用了链路追踪的 API 规范，支持多种编程语言，与平台、厂商无关，使得开发人员能够方便地添加或更换链路跟踪系统的实现，虽然OpenTracing不是一个标准规范，但现在大多数链路跟踪系统都在尽量兼容OpenTracing。目前业界主流API标准的就有 SkyWalking、Jaeger、Zipkin、Open Telemetry、 Pinpoint、CAT等。
SmartOps由于内部服务特殊性，目前选用业界主流Skywalking作为APM系统服务链路追踪进行日常服务定位及排错。在追踪系统，平台更关注请求的质量和服务可行性，利用其优化系统排查问题。
在Metrics方面，主要利用云平台告警结合Prometheus+Grafana的方式实现，并配合外部站点探测实现全场景平台Metrics指标分析及告警，配合高可用架构及云原生故障自愈能力能最大程度保障系统SLA。
日志系统、度量系统、追踪系统这三个纬度所关注的重点不同，日志系统用于记录应用或系统事件，日志也是排查问题和取证的主要依据；度量系统更多关注事件聚合，当达到设置告警，关于进行系统状态的反馈及后续的自适应策略；APM系统帮助我们更深入全面了解环境、可视化整个应用程序和基础架构堆栈，应用场景丰富并且提供全链路追踪。
服务化原则：使用微服务架构，服务内功能高度内聚，模块间通过公共功能提取增加软件复用程度，从架构层面抽象化业务模块关系，标准化服务流量传输，帮助业务模块基于服务流量的策略控制与治理；
弹性原则：系统的部署规模可以随着业务量的变化自动伸缩，无须根据事先的容量规划准备固定的硬件和软件资源，而且可以动态扩容，降低企业IT成本；
可观测原则：在云分布式系统中，主动通过日志、链路跟踪和度量等手段，让每次业务请求获悉背后服务的调用耗时、返回值，下钻到每次第三方软件调用、SQL请求、节点拓扑、网络响应，使运维、开发和业务人员实时掌握系统情况；
所有过程自动化原则：通过 IaC（Infrastructure as Code）、GitOps、OAM（Open Application Model）、Kubernetes operator 和大量自动化交付工具在 CI/CD 流水线中的实践，一方面标准化企业内部的软件交付过程，另一方面在标准化的基础上进行自动化，通过配置数据自描述和面向终态的交付过程，让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化；
零信任原则：零信任对访问控制进行了范式上的颠覆，引导安全体系架构从“网络中心化”走向“身份中心化”，其本质诉求是以身份为中心进行访问控制；
架构持续演进原则：云原生架构本身应该是一个具备持续演进能力的架构，而不是一个封闭式架构，在演进过程中需注意对新建应用架构控制策略及对遗留系统迁移改造成本考虑及风险评估。
目前，安畅SmartOps混合云管平台已沉淀众多行业客户，在稳定、安全、实用方面赋能不同领域用户进行现代化云上管控：
在互联网行业，SmartOps可以颠覆传统的基础设施及运维模式，带来了可编排、极速全局管控、自服务运维的能力；
在教育行业，借助SmartOps的资源纳管能力和资源抽象能力，助力高校填补公有云技术迭代与高校技术管理人员技能间的鸿沟，打破院级/科系数据孤岛，面向高校用户提供统一的服务目录；
在政务行业，SmartOps支持国产化部署，满足基础设施自主可控，以平台的实时统一监管、宏观调度、审计等能力，帮助客户降低成本和运维压力，实现不同部门统一规范，推动跨部门业务协同；
在工业领域，基于SmartOps预算管理、资源交付、资源运营能力，大幅提升资源的交付效率及资源使用率，从而降低项目成本。
近年来商业世界的发展趋势，数字化转型的出现使得企业越来越多业务演变成数字化业务，数字化对于业务渠道、竞争格局、用户体验等诸多方面都带来更加严苛的要求，这就要求技术具备更快的迭代速度。架构的演进不是一蹴而就，而是不同时期为了更好的支撑业务发展进行适配发展的行为，为了技术而进行不合适的过度架构设计是不负责任的行为，将业务与架构共同朝着既定目标共同成长才是最佳策略。如果您企业的数字化转型之旅需要一位专业的伙伴，那拥有海量云上最佳实践的安畅或许是您最好的选择！
