微服务架构是近两年兴起的一个概念。在此之前，互联网公司在处理生产环境分布式系统的实际问题时，其实已经使用了微服务架构。比如原来的淘宝系统也是单体应用。为了应对用户数量增长带来的系统处理能力不足的问题，淘宝对其应用系统进行了一系列的服务拆分和改造。淘宝开源的Dubbo框架和企业内部使用的HSF框架都是微服务架构的成果。本文将从架构选择、开发测试环境相关工具支持、人员分工及开发部署流程、相关设计及注意事项等方面简要阐述微服务架构项目实践经验。***，我们将结合实践经验，探讨微服务架构下提高开发运维效率的实际需求，进一步明确本项目实现的容器服务管理平台的完备性要求。项目背景及微服务架构选择本项目是一个企业级的容器服务管理平台。该平台的功能是基于容器的应用运行环境管理，以及应用开发阶段的持续集成和持续发布。简单理解平台的核心功能之一就是管理复杂应用的开发运维环境，提高微服务架构下的开发运维效率。项目开发背景如下：一、系统具有典型分布式应用系统的特点：平台服务器配置不高，如华为RH1288等低配置服务器，硬件故障是允许的；系统平台需求可根据实际用户数量进行规模化部署，保证硬件资源的合理利用；由于系统平台需要运行多个企业应用开发和运行环境，可靠性非常重要，不允许出现单点故障。其次，这个系统的功能比较复杂，需要从架构的角度将系统划分为多个层次和多个子系统。不同层次、不同子系统需要根据具体情况采用不同的开发语言，由不同的开发团队完成。第三，项目组成员由多个城市的远程团队共同开发，统一的开发环境和协同工具必不可少。综合以上项目背景，本项目选择基于微服务架构开发项目。用于开发、测试、部署的工具集是“工欲善其事必先利其器”。借助合适的流程和相关工具集，可以提高微服务架构下应用开发的效率。本项目采用DevOPs流程，选择了一套相关工具来实现应用开发管理，提高开发、测试和部署的效率。代码库：本项目使用分布式代码库Gitlab。它的功能不仅限于代码仓库，还包括审查（codereview）、问题跟踪（issuetracking）、wiki等功能。它是用于代码管理和远程团队沟通与协作的工具。***。Docker镜像仓库，Docker：本项目在整个软件开发过程中都使用容器，以容器作为应用发布的载体，应用开发环境和测试发布环境都运行在Docker容器中。Docker对于复杂的开发和运维环境管理具有先天优势。目前，国内外大部分互联网公司都将Docker应用到其开发或生产环境中。K8s：本项目使用Kubernetes作为容器调度管理的基础环境，K8s负责调度管理开发环境和测试环境的Docker容器。Jenkins：快速部署和发布离不开老牌持续集成之星Jenkins。本项目通过Jenkins任务构建代码，将应用打包成Docker镜像，最后发布到K8s环境运行容器。Shell脚本：编写Shell脚本，将项目分支、应用发布等开发阶段的配置管理工作自动化，降低运维门槛，提高配置管理和运维效率。WIKI：Gitlib上的WIKI功能比较简单，所以项目组选择了dokuwiki作为远程团队协作交流的工具。团队成员可以将设计文档、知识共享文档、公告信息等信息更新到wiki，进行协同开发。ZenRoad：为了方便开发计划、开发任务和bug的关联，本项目使用ZenRoad进行开发任务和bug管理。分工与开发流程微服务架构应用的开发部署复杂度远大于单体应用。运维人员手动配置管理显然难以应付。DevOps提倡自动化任务处理，实现软件交付和基础设施更新，可以说是微服务架构应用开发和运维的必要条件。本项目采用DevOps理念的开发流程进行开发。自动化部署运维需要工具。同时，DevOps强调软件开发人员与其他IT人员和管理人员之间的协作和沟通。因此，明确的分工和开发过程是与工具同等重要的因素。通俗地说，有了工具，大家要懂得使用工具，愿意使用工具，才能真正达到提高研发效率的目的。项目组的主要工作成员无非是做三类工作：开发、测试、系统管理。这里只说明与传统企业应用开发过程中三类人员所完成的工作略有不同的工作内容。开发者：a)开发者做开发设计，需要将设计中与接口相关的部分更新到wiki，供调用者审核调用。b)开发者除了编写程序逻辑外，还需要注意单元测试用例的编写，因为分布式应用的联调相对复杂，联调前在编写单体服务时做一次测试可以提高开发效率。c)由于本项目使用Docker容器作为发布载体，开发者可能需要修改DockerFile模板中的一些参数，以便在部署阶段将编译后的代码打包到镜像中。与传统的开发方式相比，这是对开发人员的额外要求。看来对所有开发者理解Dockerfile的要求有点高。实际上，各个子项目中的DockerFile和脚本一般都是主系统配置管理员在搭建项目框架时写好的模板。如果开发人员不了解相关技术，也可以与配置管理员沟通需求，由配置管理员修改相关文件。测试人员：测试人员的工作没有什么特别的，但是需要注意除了每个Sprint阶段的测试之外，还需要配合开发人员进行持续集成测试；系统配置管理器：一般的DevOps开发方式依赖于云基础平台，并且是自动化的发布工具，所以相对于传统的开发方式，对系统配置管理器的技术要求会比较低。但是，我们项目开发的目的是搭建一个能够支持DevOps流程的平台，而其开发本身并没有相应的平台基础。因此，我们项目初期的系统配置管理工作由架构师完成，主要需要做以下事情：a)项目团队开发的部署和运行需要使用公共服务组件，比如zookeeper注册中心、DockerRegistry镜像仓库、Database等；b)为子项目编写在git上分支的脚本，方便测试发布时分支；c)为各类应用编写Dockerfile，以镜像方式发布部署；d)制作或在网上找现成的开发站点所需环境的Docker镜像，推送到项目开发使用的私有镜像库；e)编写shell脚本将子项目打包成Docker镜像，并推送到镜像仓库。f)在Jenkins上配置自动编译或部署任务，实现持续集成和部署。本文将简要介绍项目的开发、部署联调、测试发布的流程和规范，并举例说明项目各阶段使用的一些自动化脚本工具。代码分支管理：如图所示，在git上创建的每个项目至少需要建立两个分支，develop和master。开发者只有向develop分支提交代码的权限，平时的持续集成和联调从develop分支获取代码。在每个Sprint阶段测试和发布版本时，配置管理员从develop分支创建一个发布分支用于测试。当测试修改bug时，开发者只需将修改后的代码提交到对应的测试Release分支即可。当测试版本稳定后，配置管理员会将代码合并到Master分支。自动化部署发布：项目借助Shell脚本、Dockerfile、K8s配置文件和Jenkins任务实现自动化持续集成和部署。配置管理员在项目目录下编写的脚本文件结构如图2所示。a)为分支创建shell脚本，示例见附件1；#!/bin/bashif[-z"$1"];然后cat
