微服务架构

微服务架构是一种设计方法，其中应用程序被分解为一组较小的、相互独立的服务，每个服务运行在自己的进程中，并通过轻量级通信机制（通常是 HTTP API）进行互动。

微服务架构的优势包括：

• 可扩展性：可以通过添加或删除服务来轻松扩展应用程序。
• 独立性：服务彼此独立，因此可以单独开发、部署和维护。
• 容错性：如果一个服务出现故障，它不会影响其他服务。

• 敏捷性：微服务架构使开发团队能够更快速、更高效地构建和部署应用程序。

为什么选择 Golang 构建微服务

Go 是一种高效、现代化、快速增长的编程语言，非常适合构建 Web 应用程序。其特点包括：

• 并发性：Go 提供内置的并发支持，使其非常适合构建高性能 Web 应用程序。
• 简单性：Go 具有简洁的语法和健壮的标准库，这使得更容易编写和维护代码。
• 工具链：Go 提供了一个丰富的工具链，包括用于构建、测试和部署应用程序的命令和工具。
• 社区支持：Go 拥有一个大型且活跃的社区，为开发人员提供支持和资源。

容器化实践

Docker是一种轻量级的容器化技术，能够使得您的应用程序在任何地方运行，并且具有隔离性和可移植性。

为了使 Go Web 项目能够在 Docker 容器中运行，我们需要完成以下几步：

1. 创建 Dockerfile，其中包含构建和运行应用程序所需的指令。
2. 使用 docker build 命令构建 Docker 镜像。
3. 使用 docker run 命令运行 Docker 容器。

示例

下面是一个简单的 Go Web 项目的示例 Dockerfile：

FROM scratch

WORKDIR /app

COPY ./go.mod ./go.sum ./main.go ./
RUN go build -o main

CMD ["/app/main"]
  

要构建 Docker 镜像，请运行以下命令：

docker build -t my-go-app .
  

要运行 Docker 容器，请运行以下命令：

docker run -p 8080:8080 my-go-app
  

这将运行一个容器，其中包含我们的 Go Web 应用程序，该应用程序在端口 8080 上侦听传入连接。

结论

通过使用微服务架构和 Docker 容器化，我们可以构建和部署可扩展、独立、容错和敏捷的 Web 应用程序。Go 是一种非常适合构建微服务的编程语言，而 Docker 是一种容器化我们的应用程序的强大工具。

网易消息推送系统微服务化实践

微服务加上如今的服务发现，在基础设施即代码（指使用脚本配置计算基础设施，而不是手动配置计算机的方法）的过程中，我们正在不断的尝试各种实践方案。如何在云基础设施下结合业务场景，通过负载均衡、服务发现、容器化来实现业务链自动化，这就是本文给大家带来的分享。

困扰和烦恼

首先来看下我们其中一个平台之前的大体架构：

随着业务的递增，我们遇到了以下的问题：

什么是服务发现？

在分布式微服务架构中，一个应用可能由一组职责单一化的服务组成。这时候就需要一个注册服务的机制，注册某个服务或者某个节点是可用的，还需要一个发现服务的机制来找到哪些服务或者哪些节点还在提供服务。

在实际应用中，通常还都需要一个配置文件告诉我们一些配置信息，比如数据连接的地址，Redis 的地址等等。但很多时候，我们想要动态地在不修改代码的情况下得到这些信息，并且能很好地管理它们。

然而，服务发现组件记录了（大规模）分布式系统中所有服务的信息，其它服务可以据此找到这些服务。DNS 就是一个简单的例子。当然，复杂系统的服务发现组件要提供更多的功能，例如，服务元数据存储、 健康 监控、多种查询和实时更新等。服务发现是支撑大规模 SOA 的核心服务。

Consul 介绍

Consul 是一个支持多数据中心分布式高可用，用于服务发现和配置共享的开源工具。它具有开箱即用、可跨系统平台部署（在任何基础架构上连接任何应用）等特点。Consul 的三个主要应用场景：服务发现、服务隔离、服务配置。Consul 关键特性：

Consul 之服务发现

Consul 之服务配置

首先 Consul 集群内的所有数据都是可共享的，任何一个节点都是可以同时获取到集群内最新的数据信息。然后通过一些例如 Key/Value、Server、Node 等等数据进行文本内容渲染，从而达到一个变更的全程实时自动化。例如根据 Key/Value 信息渲染：

例如根据服务信息渲染：

在传统运维方式上可以有哪些改变

传统方式如何向微服务化转变

入口的动态自动化

容器和服务发现始终只是在对内部的通信实现，如何将这些服务快速方便的对外实现通信，并且能够高度自动化呢？我们通过将 HA 作为各类后端服务的对外统一入口；配置 backend 服务时，配置的是 Consul 中的服务域名。从而作为内部和外部通信的一个通信转发枢纽。

HA 的域名动态解析

首先看看容器化下的服务地址是怎样通过 Consul 完成变更的。

然后为什么是 HA 的 DNS 动态解析？这个不是 DNS 的锅么？

在常见的代码更新、服务配置变更、迁移、扩容等需要容器重建时，会导致 N 个容器同时发生 Consul 域名解析变更（当然也是预期内的变更），这个时候需要使用了 Consul 域名的服务在访问失败时能够去重新解析一次域名获取新的 IP，完成解析的自动变更。

需要注意的是这里有个坑，原来使用 HAProxy 1.5 版本，后端服务配置使用域名时，启动服务后只解析一次（和 Nginx 类似）域名，这时如果已解析的服务挂掉或进行了切换等，即使异常节点已屏蔽，访问 HA 时依然会出现例如 503 等异常（即使 DNS 已经发生了改变，但 HA 服务本身缓存了旧 IP 等于地址未更新）。后续查询官网得知 HAProxy 1.6+ 才支持了动态DNS。

如何利用 HA 的域名解析配置实现后端路由动态化

首先，HA配置增加一段 resolvers 定义，用来实现 HA 的域名动态解析。

其次，对不同业务环境隔离的路由分发，同样需要增加 HA 的 frontend 配置进行流量隔离。

最后，在 HA 的 backend 处引用前面定义的 resolvers 和 frontend，实现到后端RS的动态转发。

WEB 配置内容自动托管

文件内容更新：使用 Consul 的 K/V watch 功能，一旦有新服务上线/下线时，配置自动化接入和自动化下线流程，更新 Web 服务配置并 reload（触发脚本完成），完成整个流程的自动化。

后端服务自动加入集群

云主机节点自动初始化自身后进行服务注册，自动导入流量。

总的来说，我们根据业务特性，使用 HA、Consul、Docker 这样的一个组合来实现高度可扩展性、稳定性，及流程的基本全自动化过程。

业务链高度自动化，从上线到下线，整个流程包括服务上线、配置变更、产品发布、功能迭代、下线回收等全自动衔接完成。

整个过程至少实现了：

现在（图 A）和原有（图 B）对比如下：

作者：丁易锋，网易 游戏 资深运维工程师，主要工作方向为网易 游戏 项目运维支持。专注于运维技术的突破，以及为产品提供更加高质量和便捷的服务支撑。

Kuboard 从微服务视角理解 Kubernetes

当我们谈论微服务的时候，总避免不了说 Spring Cloud / Dubbo，这些微服务架构的采用，确实达到了我们对他的期许：分布式、熔断/限流、高可用、可扩展、分离关注、链路追踪、小团队快速迭代。

然而，微服务架构的引入在解决单体应用的一些问题的同时，也给我们带来了新的复杂度：

作者在落地 Spring Cloud 微服务架构的过程中，设计了如下图所示的微服务参考架构：

该图的左侧是 DevOps 平台，涵盖构建、测试、包管理、部署及运维、监控及评估。右侧是运行时平台，分成互联网层、展现层、微服务层、数据层。

运行时环境采纳了微服务架构后，因为技术组件的多样性、业务领域的多样性，导致了微服务拆分之后，产生了数十个微服务可部署单元。这个情况给技术团队带来了前所未有的挑战：

在解决这些问题的过程中，最终摸索出了一套以 Kubernetes 为关键环节的微服务 DevOps 平台。

如上图所示，假设有20+ 开发人员，

在单体应用的时候，即使是手工打包也是能够完成每天发布新版本的要求的。但是在微服务环境下，这个工作就必须交给 DevOps 的 Pipe Line 来完成。

DevOps 在构建阶段的主角是 GitLab、npm、maven、docker、Harbor等工具集，在部署和运维环节的主角就是Kubernetes了。

最开始尝试容器化的时候，使用了 docker、docker-compose，但是docker-compose的编排能力有限，在考虑分布式方案时，从 docker swarm、kuberenetes 之中选择了 Kubernetes，然而，Kubernetes 相较于 docker-compose，有一个很高的学习门槛，集群的安装管理、YAML 文件的编写、多环境（开发环境、测试环境、准生产环境、生产环境）的配置、分布式环境下的问题诊断和性能优化等，一系列的问题需要解决，团队中也出现一些抵触情绪，对新事物持观望的态度。

Kubernetes在诸多大厂的成功实施，仍然让我们坚信这条道路的正确性。为了解决 Kubernetes 学习门槛高、YAML 文件编写复杂等一系列现实中的困难，我们研发了Kuboard ，一款 Kubernetes 的图形化管理控制工具。

Kuboard诞生于 Spring Cloud 微服务落地的实践过程中，他在管理和使用 Kubernetes 的时候，也更多地是从微服务的视角来看待 Kubernetes。

具体体现在如下三个视角：

从管理和部署微服务的视角来看，微服务应用是分布式应用，应该部署在一个分布式集群当中，这个集群由诸多计算资源和存储资源组成，微服务本身不应该关心最终使用了哪个计算节点，持久化存储被存放在什么位置；为了更好地利用资源，一个集群应该被划分成多个名称空间，每个名称空间内可以部署一整套微服务应用，名称空间之间不应相互干扰。

如下图所示： Kuboard集群概览界面

Kuboard集群概览视角，映射了 Kubernetes 中的如下几个重要概念：

在集群概览界面中，点击一个名称空间，可以进入 Kuboard 名称空间界面。一个名称空间内部，是微服务部署相关的所有重要元素。与本文开头的微服务参考架构相匹配， Kuboard认为，微服务的主要分层包括：

如下图所示： Kuboard 名称空间截图

Kuboard名称空间视角，映射了 Kubernetes 中的如下几个重要概念：

Kuboard名称空间界面中，还为典型的运维场景提供了便捷的操作入口，例如：

从名称空间界面中点击一个工作负载（微服务），可进入Kuboard工作负载编辑器界面。 Kuboard当前已经支持的工作负载 Workload 类型有：Deployment / StatefulSet / DaemonSet。

Kubernetes 中，与 Workload 相关的概念非常多， Kuboard从微服务部署的实际需要出发，按照下图所示的方式理解这些相关概念：

Kuboard工作负载视图中，关联的 Kubernetes 中如下几个重要的概念：

Kuboard认为，掌握这些概念并正确理解这些概念的关系之后，就可以胜任使用 Kubernetes 部署微服务的工作，为了使事情变得更简单，避免编写冗长的 YAML 文件， Kuboard以此概念为基础，设计了Kuboard工作负载编辑器，如下图所示：

如何监控和评估微服务的运行状况，并根据监控结果进行问题的定位和诊断？基于 Kubernetes / Spring Cloud / Java 等，开源社区已经提供了非常丰富的监控组件，例如：

各种监控系统各有侧重，如果想要取得比较好的监控效果，必须克服如下几个困难：

Kuboard认为，应该以微服务视角的视角快速查看到该无服务在不同层面的监控结果。因此，在Kuboard的工作负载（微服务）查看界面中，可以直接点击进入不同监控系统对应的监控结果，无需再监控系统内反复查找。如一下截图所示：

点击图中 Nginx 监控 、 容器组监控 、 所在节点监控 等按钮，可以直接打开该容器组对应的监控界面。因为篇幅的限制，此处不再展开描述，请到 Kuboard官网 提供的在线Demo体验具体的监控效果。

Kuboard产生于 Spring Cloud 微服务落地的实践中，并在许多的实际项目中投入了使用，以微服务的视角理解和审视了 Kubernetes，并基于Kubernetes为用户提供了4个微服务视图：

目前Kuboard已经可以免费供大家使用，感性的朋友可访问获得详细的信息。