论微服务架构

试题四论微服务架构及其应用

微服务提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通。在微服务架构中，每个服务都是一个相对独立的个体，每个服务都可以选择适合于自身的技术来实现。每个服务的部署都是独立的，这样就可以更快地对特定部分的代码进行部署。

请围绕“论微服务架构及其应用”论题，依次从以下三个方面进行论述。

1.概要叙述你所参与管理或开发的软件项目，以及你在其中所承担的主要工作。

2.简要描述微服务优点。

3.具体阐述如何基于微服务架构进行软件设计实现的。

摘要：

2022年3月，我负责了某公司基于云原生理念的“自动化运维系统”的建设项目，由我担任系统架构设计师，负责系统架构设计工作，在该项目的实施过程中，该项目主要采用分层架构，主要分为表示层、业务逻辑层和数据层，其中业务逻辑层的设计我们选择了微服务架构，多个服务采用grpc协议进行通信，所有的服务采用容器化的方式部署在kubernetes集群中，每个容器使用kubernets中的deployment进行管理，采用deployment可实现应用发布时，新版本运行成功后才会删除旧版本，确保应用发布高效准确，提高系统的稳定性。该项目总投入近450万，历时15个月，于2023年6月交付至今，不仅帮助运维人员高效、安全的管理云上应用和后端服务器资源，同时帮助开发和测试人员实现应用的快速迭代和测试，大大提升了团队之间的协作效率，消除了运维和开发之间的壁垒，得到了用户的一致好评。

正文：

随着云原生技术的发展，企业也逐渐引入相关技术，在基础设施层，越来越多的企业开始购买云上服务器，如应用服务器企业可选择阿里云的ECS服务器，数据库服务器企业可选择阿里云的RDS，DNS服务企业可选择阿里云的域名解析，云上资源购买十分方便，在页面中点击几下即可购买成功，但在实际工作中，不能随意购买，需要结合企业成本和服务器资源使用情况来综合考量，避免资源浪费，所以对云上资源的成本、资源使用情况的可视化管理就很重要。同时，随着容器技术和微服务架构的发展，企业应用也都选择微服务架构，采用容器的方式部署在kubernets集群中，在这种情况下，应用的快速发布、容器资源管理、监控告警就显得尤为重要。

为了实现云上资源的可视化管理和基于云原生应用的快速发布，我所在的公司决定开发一个“自动化运维”系统，我们称之为云平台，并在2022年3月正式启动该项目的建设工作，我被任命为系统架构设计师，负责系统架构设计工作。该项目总投入450万元人民币，建设周期从2022年3月至2023年6月截止，历时15个月。该系统主要包括应用中心、发布中心、监控中心、成本中心、容器中心、权限管理和变更管理七大模块，应用中心是整个系统的数据中心，其他模块的功能都围绕“应用”来进行资源的展示和操作；发布中心以“应用”为单位，向用户提供应用的快速发布功能；监控中心以“应用”为单位，向用户提供应用的监控告警功能；成本中心以“应用”为单位，向用户展示每个应用的成本；容器中心以“应用”为单位，展示应用的相关容器资源；权限管理是对用户分类，使得不同的用户可看到不同的模块；变更管理主要对云上资源的变更进行管控，避免对云上资源的误操作导致系统故障。

在架构设计阶段，在应用逻辑层，我们选择了微服务架构，主要由于微服务有如下优点：1.复杂应用解耦，相比于传统单体应用，微服务将一个庞大的单体应用进行解耦，使得每个应用更轻量，便于代码开发和管理，相比于SOA架构，微服务是去中心化的，每个服务之间可相互调用。2.独立，将服务进行拆分后，每个服务可由单独的团队或个人进行负责，实现服务的开发和迭代更加独立。3.技术选择灵活，每个服务可选择不同的前后端编程语言进行开发，每个服务通过http或grpc进行数据船体。4.可扩展性强，后期功能的迭代，可通过增加新的服务来实现新的功能。5.可维护性强，每个服务在发布或宕机时，不会导致系统宕机。基于以上原因，我们选择了微服务架构，接下来将介绍该项目基于微服务架构的实现细节。

针对该系统业务逻辑层，我们将其划分为应用中心、发布中心、监控中心、成本中心、容器中心、权限管理、变更管理、人员管理等多个微服务，在技术选型上，每个微服务都选择了golang语言进行业务逻辑的开发，微服务之间数据传递选择了基于proto的grpc协议，并选择了开源的kratos框架，在框架的选择时，基于golang的框架有gin、beego、kratos，但是最后我们选择了kratos，主要是由于其对grpc和http协议的支持更加友好，书写一份proto就能同时生成http、grpc两种协议的入口代码，开发效率高，可让开发人员把更多的中心放在业务逻辑上。

在团队协作时，每个服务在gitlab中创建一个项目，代码在gitlab中集中管理，每个服务对外接口描述文件是proto文件，在proto中详细记录了每个接口的入参和出参，并在proto中书写相关的描述信息，说明接口的用途，当一个服务的开发人员想要调用另一个服务的接口时，直接查看对应的proto文件即可，同时可直接根据proto生成代码，在自己的项目中使用。

在容器化部署上，我们选择了kubernets中的deployment资源进行服务的容器管理，主要是因为deployment能实现在应用发布时，新版本运行成功后才会删除旧版本，可提升服务的可用性，并且每个微服务配置两个deployment资源，分别在两个kubernets集群中，当一个kubernets集群出现问题时，另一个集群中的实例还能继续提供服务，提升系统的可靠性。

在服务注册和发现上，我们使用kubernets中的service实现服务的注册、发现和负载均衡，以发布中心和应用中心为例，在应用上线时，我们会为应用中心和发布中心分别创建两个service，名称分别为cloud-app和cloud-devops，当发布中心进行应用发布时，会获取应用的环境、集群、负责人等信息，就可以直接在代码中调用cloud-app，就能对应用中心发起grpc调用。

在弹性伸缩上，我们使用kubernets中的hpa实现快速扩缩容，我们为每个微服务的deployment配置对应的hpa资源，目前主要配置根据cpu指标的弹性扩缩容，为每个微服务配置当cpu指标超过80%时，就进行扩容，实现应用的高性能。

经过近15个月的项目开发，“自动化运维系统”顺利投入使用，开发人员和测试人员可通过该系统实现应用发布的自动化，无需运维人员的协助，消除了运维和开发的固有壁垒；运维人员可通过该系统高效管理云上资源，实时查看云上资源的使用率和成本，减少资源浪费，提高资源使用率。当然，在本项目中还有一些不足之处，在进行云上资源成本统计时，最初我们通过阿里云的费用接口来拉取各个产品的成本，由于产品很多，写了很多逻辑，后来通过和阿里云的技术人员沟通，可以在阿里云平台上将所有产品的费用一键转储到oss中，直接通过oss的sdk即可快速查询所有产品的费用，后来我们开发人员快速修改下成本获取的逻辑，并没有对项目产生什么影响。由于架构合理且考虑周全，进展顺利，得到了公司技术人员的认可，大大提高了技术团队的协作效率。