总结

[astrisk]

毕业设计

这几年工作主要在做容器平台和微服务基础设施相关，这次课程很多涉及到架构方面，跟自己的工作内容上还是有很大的匹配度。所以根据课程所学以及工作内容，经验思考进行总结。整体的内容会跨越：容器云平台架构；微服务架构；研发流程和工程能效。

工作背景

由于最近两年的在公司的项目中运用了容器化和微服务架构以及相关技术。但是在实际项目实施过程中，涉及到多个部门和团队的协作，尽管都是微服务和容器化，但是从整体和技术细节都暴露出很多问题。通过训练营的学习结合自身项目经验，对相关内容进行总结以优化现有技术架构。

技术架构优化

公司的主要面向2B的政企客户，而且基本上都是本地化项目。由于不同的客户，在IT基础设施和理念上还是存在不小的差异，有传统的物理机架构，有正在上云的，也有已经 IaaS+PaaS+混合云架构的客户。同时我们项目的非功能需求主要偏向于稳定性，可靠性和安全性，成本其次，基本上不存在高并发。针对这种类型的项目，主要技术架构设计如下图

• 双态架构
  • 对于重资源服务采用虚拟机或物理机方式，这样能够保证这些存储/中间件的最大性能和稳定性。
  • 对于业务服务采用无状态设计，采用容器化方式在容器平台上进行。
• 微服务架构 庞大的微服务数量，无论是开发协作还是运维管理都是非常麻烦的事情，如果微服务生态不全，对于项目实施是个很痛苦的事情。完善微服务基础设施，提升平台和微服务的可观测性，提升开发和运维效率。
• 分层组合架构 由于面对异构的客户环境，在架构设计规划上，按照不同功能层面进行分层建设，以便适合不同客户基础设施。
  • 微服务治理和容器平台分开：假如客户有现有的容器平台，在架构上选择客户的容器平台+微服务治理+业务微服务这样能方便灵活进行交付。增加整体架构的灵活性。
  • 业务微服务和微服务治理松耦合：通过sidecar或不同的基础镜像层+业务代码灵活适配现有的几种微服务治理框架。这样面对客户环境中不同的微服务基础设施能够通过替换微服务治理层灵活适配。
  • 基础中间件SDK：对于各类中间件/存储，抽象出SDK，业务微服务通过SDK访问中间件。这样能够灵活适配原生中间件/存储以及各类云化中间件产品。

容器云基础设施

容器基础设施承载上层容器应用运行，其自身的稳定性，可靠性，安全性，可扩展性直接关系到业务系统的稳定以及客户对业务应用体验。所以在进行平台部署规划时需要遵循以下架构设计原则：

• 弹性原则

  • Proxy
  • Nginx节点可以根据实际业务流量进行横向和纵向扩容
  • 如果采用负载均衡，则可以结合智能DNS+多负载均衡实例方式扩容负载均衡
  • 容器平台
  • ETCD
    • 大多数情况下，单个ETCD集群就可以支撑容器平台
    • 大规模容器平台，可以使用多个ETCD集群，比如把容器网络资源，集群事件采用独立的ETCD集群。
  • 负载节点
    • 在集群规划时需要考虑负载节点的扩容需求。特别是公有云VPC网络规划时，需要预留足够的IP资源来应对负载节点的横向扩容
  • 容器网络资源
    • 容器网络资源（网段）规划需要预留足够IP资源，以保障容器平台在扩容后能够承载足够的容器服务。
  • 日志平台
  • 日志平台为分布式集群，可以根据实际情况进行横向扩展集群。
  • 监控报警
  • 监控报警平台采用分布式集群方案，可以根据实际情况进行横向扩展集群。

• 安全原则

  • 根据安全架构的边界模型设计，在网络设计上把容器平台划分为多个网络逻辑边界区域。
  • Proxy: 代理层，外部流量入口。代理层根据用途再细分为业务流量代理和运维管理代理。容器平台无论是基础服务还是容器集群不直接对用户暴露，只通过代理层进行访问，以此减少攻击面。
  • Worker: 容器平台负载节点，运行业务容器服务。负载节点根据节点用途进行细分，建立特有的Edge（边缘）节点，用来路由代理层到集群的流量。另外可以根据实际需求，把不同环境分布在不同的负载节点上，起到不同环境使用资源的物理隔离。
  • Master: 容器平台存储集群和master节点。
  • 基础服务: 日志和监控报警平台

• 高可用原则

  • Proxy
  • 代理层采用SLB+Nginx保障容器平台流量入口高可用
  • 如果客户没有SLB，则采用Nginx+keepalived+VIP保障容器平台流量入口高可用
  • Master
  • ETCD集群节点数量可以是3，5，7节点数量。一般选择3节点即可，如果需要提高可用性，可以选择5或7个节点，不能大于7节点。
  • 如果是基于公有云部署，为了进一步提高可用性，可以采用多AZ部署ETCD集群。
  • Worker
  • 负载节点规划时，必须需要考虑冗余节点。以防集群中负载节点出问题后，上面的容器可以调度到冗余节点以致不影响业务系统
  • 即使是小规模集群，负载节点数量最好也要大于2
  • nexus
  • 如果需要考虑registry的高可用，可以把nexus的数据存储在S3存储中，nexus作为无状态部署2份

• 可观测性原则

  • 容器平台提供立体化的监控报警平台
  • 监控报警涵盖：虚拟机，容器平台，容器，服务以及分布式跟踪和服务metric信息
  • 平台日志涵盖：虚拟机，容器平台主进程，容器日志等

• 资源隔离原则

  • 为了保障容器平台整体稳定性和性能，平台部署遵循资源隔离原则。
  • 平台各个组件采用独立部署，即使是混合部署，也只是关系比较紧密且不容易导致资源冲突的进程。

• 成本优化原则

  • 平台各个组件根据负载特点采用不同规格资源，在降低成本的同时，保障性能和稳定性
  • 如果资源紧张，辅助系统（日志和监控）前期可以采用单点部署，后期扩展成集群

根据如上设计原则， 容器平台架构图如下

微服务架构优化

由于公司各个团队的技术栈和技术能力存在差异，在一个大项目中集成多个团队的微服务进行整体交付就暴露出来很多问题，无论是研发配合还是运维都比较难受。所以着力进行微服务基础设施统一建设和接入，这样不仅能提升研发效率。

• 微服务治理 进行统一的微服务治理框架/平台开发接入，拉取各个团队的微服务治理技术以及治理水平，保障多个团队作为统一技术标准进行交付。同时由基础架构团队进行微服务基础平台和SDK开发，业务线团队只需要按照统一标准进行接入。降低技术重复开发/研究成本。
  • 统一微服务注册中心
  • 统一微服务配置中心
  • 统一微服务Metric监控和日志
  • 统一微服务分布式跟踪
  • 统一异常处理和响应状态码
  • 微服务网关
• 微服务配置管理 各个团队在配置管理上如论是技术还应用上存在很大差异。在多团队交付时，配置管理存在管理方式多而杂；配置管理没有基本原则和套路，导致配置边界不清晰，配置相互覆盖，修改维护困难。项目初次部署调试成本极高。 结合课程中的实践，进行相关配置管理优化：
  • 明确配置分类
    • 环境变量
    • 静态配置
    • 动态配置
    • 全局配置
  • 定义配置基础原则
    • 配置和代码分离
    • 显式服务依赖配置
    • 本地和线上分离
    • 固定和外部配置
    • 配置简单化
    • 配置适当灵活
    • 命名规范化
• 容器基础镜像优化 不同的团队以及人员对于容器化的理解程度不一样，跨团队交付时，遇到过很多问题，例如：镜像太大，导致本地化交付传输成本太高；镜像未考虑安全；基础镜像选择有有问题。针对以上问题，对于容器基础镜像进行统一，由专门的团队进行基础镜像和镜像构建工具/模版进行制作，业务开发只管使用。
  • 统一基础镜像：针对时区，语言，安全和镜像分层进行处理
  • 统一镜像构建工具/模版
  • 统一镜像异常收集方式和各类语言运行时优化

业务微服务架构优化

由于项目交付涉及到公司不同团队的产品，各个产品由独立团队进行设计开发。但是组合成解决方案交付时，业务微服务从架构上看存在以下问题：

• 业务微服务分层不清晰：虽然一个项目从数量上来说包含了上百个微服务，但是从架构上看，基本上就是三层架构：前端-后端和存储。
• 业务微服务调用链路混乱：由于业务微服务内部没有进行良好的分层，区分基本服务和聚合服务，导致微服务调用链路混乱，甚至存在环形调用。
• 内部流量放大，导致一些基础服务不堪重负：比如内部微服务分别去对接SSO，导致SSO和认证服务比较脆弱。

针对以上问题，对公司不同产品架构进行重构升级，微服务架构优化如下：

• 业务微服务分层
  • 提供项目交付中的通用服务，沉淀为交付基础微服务。这些基础微服务给各条产品提供基础功能，例如：用户中心，文件中心，SSO认证以及公司特定技术服务（不太方便提供公司具体业务领域）等。
  • 增加BFF层聚合微服务。由于每个项目都会涉及到客户定制服务，这些服务提升为比较薄的一层聚合服务，提供定制会需求。这样以后如果有新项目来，交付团队主要是根据客户定制开发BFF层。比如客户门户以及一些具体涉及客户业务流程的定制。
  • 统一微服务网关以及内部微服务认证。
    • 微服务网关采用Gateway core + plugins方式进行设计开发。网关团队服务网关core和通用plugins开发，同时提供定制化plugins开发指南。不同团队可以根据core+通用plugins进行组合集成使用，也可以进行自定义plugins开发。
    • 在网关处进行统一调用认证服务认证，并在网关传递用户基础信息和token，简化内部微服务各自认证，减轻SSO服务负载和认证复杂度。

研发流程优化

面对大规模服务和多团队配合交付大项目，基础设施和工具，技术很重要。但是如何把交付流程结合基础设施进行比较好的结合，简化团队流程，同时倡导DevOps文化，才能让整体的工程效能得到比较好的提升。 这方面主要涉及到以下几个方面：

• 代码分支管理
• 项目环境管理
• 服务发布管理
• 服务配置管理
• 数据库管理

围绕着项目交付的生命周期，如何把基础设施平台和交付中的各类角色工作进行很好的串联，疏通各个环节流程的同时，尽量简化不必要的流程，让整体流程保持短平快，以适应交付项目的节奏。同时尽可能的让流程能够自动化的，轻量级的串联各类角色，降低整体流程的学习成本。

[astrisk]

写了一天时间，还有挺多东西需要细化，后面会继续深入细化。先把作业交了。