摘要：采用微服务架构设计的原因很简单解放生产力。运行时服务缺少标准，各类实现区别很大，调试困难程度不一，集成测试更是难上加难。小伙伴们更进一步的互相提供帮助集成测试及单元测试，极大的释放了团队生产力。
Docker 自发布以来，它的影响力不容小觑，目前已经在整个行业甚至于许多大企业都得到实际的应用案例以及支持。Coding.net 作为一个创业公司，大量采用了微服务架构解耦系统，在提高开发效率的同时也引入了不少新的问题。今天在这里跟大家分享一下我们是如何采用 Docker 技术在内部推行生产环境容器化，代码化，自动化的。
微服务架构从2014年上线到如今，Coding.net 已经由早期的一个 Java war 发展成为一个系统结构复杂，独立模块很多的大型分布式程序。网站的每个小功能，比如说 GIT 协议处理、Repo 信息读取（网页展示）、Push 动态、邮件通知等等都作为一个个微型服务在云上运行，互相通过 API / RPC 调用充分解耦，互不侵入，接口明确。 采用微服务架构设计的原因很简单：解放生产力。传统 Java 基于 Application Server 的开发模型下，AS确实提供了很多运行时服务，很多功能都可以在其中实现，但是这也带来了 AS 负担过重，组件隔离性不强的问题。AS 运行时服务缺少标准，各类实现区别很大，调试困难程度不一，集成测试更是难上加难。
在这种环境下，松耦合的实际是非常可行的提高团队生产力的方案。放开手脚让小朋友们自己选择合适的程序包装方式，实现语言。小伙伴们更进一步的互相提供 Mock/Stub 帮助集成测试及单元测试，极大的释放了团队生产力。
容器化经历了早期野蛮式、爆发式的服务拆分后，Coding.net 不可避免的面临着生产环境中越来越高的复杂度问题。早期 Coding.net 的部署方式简单，一个 War 包拖入合适位置，网站就完全更新了。拆分后，变成了三五个小服务跑在十几台虚拟机上的问题。同时这三五个小服务又分别使用不同技术实现，有的是 Jar 文件运行，有的采用 Jetty+war 或者 Tomcat +war 。一批小伙伴用 Go 重写了一部分服务，还有几个小伙伴采用 Ruby 重构了另外一个核心功能。如此一来，生产环境的压力可想而知。每个组件的编译方式各不相同，启动方式和配置方式更是天差地别，甚至有好几个组件就是源代码直接运行。运维同学不光要记住所有组件的运行位置、编译方法，更要记住配置方式、依赖模型，压力山大！同时，某一天大家突然发现，我们再也不能把整个 Coding.net 在机器上跑起来了，因为谁也不知道如何才能正确安装配置各种依赖服务。
为了解决这些问题， 我们最终采用了 Docker container 技术来降低生产环境的复杂度。有个比喻很形象，Docker 把程序装进了盒子里，每个 Docker 镜像包含了完整的程序代码，运行时状态，而且有一个标准的启动接口。不管小伙伴设计的牛X程序多复杂，一个 docker run 也能把他正常运行起来。同时 Docker 还带来了版本化的集成，从此告别了不知道运行什么版本代码的问题。
代码化应用程序装进盒子后，我们还面临着盒子在哪里运行的问题。非常实在的说十几个 Container 和十几台VM 存在着比较复杂的对应关系，原因是很现实的：设计之初程序之间的 RPC 是依靠主机 DNS 地址互相通信的，就算装进了盒子里，盒子也不能轻易挪动。如果挪动盒子A，可能涉及到更改盒子B、C、D的配置。所以实际上 Explicit knowledge 在小伙伴的日常工作里变成了非常严重的问题。 这个问题的解决之道就是将依赖关系代码化。服务之间关联复杂不要紧，只要我们把各种依赖关系变成代码，计算机可以帮助自动处理相当一部分的工作。
代码化分为两大块：第一块是用一个脚本从云服务提供商那里抓去了所有机器的 host/IP 配置。 第二块是定义了一个 protobuf 文件将 Coding.net 生产环境的服务主机的对应关系记录下来。我们进一步设计了一个 Service IP 体制，自动为生产环境中的每个服务创建一个 DNS CNAME 记录，指向服务实际使用的机器 DNS A 记录。于是当有服务挪动操作的时候，DNS记录会刷新，所有的下游依赖都会重新解析DNS 到新的地址。同时，我们还自己开发了一个工具，根据记录的信息检查生产环境是否与记录存在差异，进一步可以将常用操作（如启动停止，更新，移动主机）等等包装起来，为操作人员提供一个标准的 CLI 工具，将复杂的生产环境操作变成程序。
同样道理，我们也可以按代码生成一个开发环境的定义，用一套工具同时操作开发环境和生产环境。小伙伴们一键可以在自己电脑上起停整个 Coding.net 服务云，也可以同样的命令一键起停生产环境（前提当然是有足够权限）。这样环境的统一所带来的生产力变革是非常深刻的，对公司研发的组织架构也有很深远的影响，有机会的话可以在另一篇文章里详细再说。
自动化装进盒子，能挪动，只描述了 Coding.net 宏伟蓝图的一小部分，而管理大规模生产环境的关键在于自动化。做好代码化之后，我们马上上马 Continuous Deployment ，让每一行更改过的代码一分钟内进入 Staging， 再结合自动化的 Regresssion testing 工具，自动汇报未预见的错误更改。 同时我们还有一个一键发布和回退服务，让更新变得更简单，容易。自动化的服务系统还包括 Log 的转发存储，metrics 的自动收集， Application healthcheck 等等，这些都极大的降低了小组件的运维难度，鼓励大家开发更小更独立的组件，而不是又笨又大的单体程序。
以上就是 Coding.net 服务架构的演进， 希望能对大家有所启发。在 4月23 日 QCon 全球软件开发大会“挑战全栈开发”专题上，Coding.net 架构师 孙宇聪也将会给大家分享一下如何利用 Docker等的相关技术为创业公司的全栈开发加分，提高产品质量，创造一个可持续的全栈开发环境。敬请关注4月23日下午 15:50 《Coding.net 全栈开发实践分享》。欢迎大家交流，邮件 : sunyucong@coding.net。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/26373.html
摘要：说起，必须要介绍是什么东西，为什么中小企业私有云适合使用。看一下现在的架构图开个玩笑。上面这四点导致我们必须要统一架构，最终把整个业务系统迁移到基于的类似于的私有云的平台。 本文系 ArchSummit 大会 CODING 工程师王振威演讲实录。 showImg(https://dn-coding-net-production-pp.qbox.me/c2f81423-54b9-4a7b...
摘要：是一个典型的模式架构，用户通过终端将字符流传递给。仿照的工作原理，我们在协议之上设计了，见下图真实实现中，是应用层的通讯协议。僵尸进程问题我们知道由于缺少而导致僵尸进程无法回收的问题迄今存在。进入构建环境执行命令。 Coding WebIDE 做个国内首个基于 Docker 技术的云端开发平台于4月1日正式上线。本文主要和大家分享和探讨 Docker 在 Web IDE 中运用的一些经...
摘要：期待大家的参与上海站圆满结束，嘉宾和观众热情不减，现场分享也让上海观众收获到满满的干货，期望我们未来为大家带来更多有趣的话题。 SegmentFault D-Day Docker 主题沙龙上海站，在五角场 VMware 上海研发中心完美结束，本次沙龙我们邀请具有实践经验的四位嘉宾，分享满满的干货，为开发者们介绍 Docker 技术及其应用。 showImg(https://segmen...
摘要：面对平台化的竞争，推出了调度引擎，但从未真正流行起来，因为整个行业更倾向于采用，这是第一次死亡它失去了平台之战。左耳朵耗子说过一段话，让人深以为然：我清楚地看到了 Go 和 Docker 这两种技术的生态圈发展过程。让我收获最大的并不是这些技术本身，而是技术的变迁和行业的发展。从中，我看到了非常具体的各种思潮和思路，这些更有价值...... 这些关键新技术，可以让你拿到技术的先机。这些对一个...
摘要：在中采用的共识算法是算法可以在信任程度较低的场景下避免拜占庭问题。但是由于算法本身特性限制，，才能容忍一个拜占庭节点，因此在版本下，节点数量至少是个。 作者: TopJohn原文连接：https://www.xuanzhangjiong.to... Fabric架构演变之路 Hyperledger Fabric是目前主流的开源联盟链产品之一，自2016年5月12日开辟代码仓库之日起，...
阅读 2681·2021-10-08 10:12
阅读 3660·2021-09-22 15:45
阅读 2337·2019-08-30 15:52
阅读 2461·2019-08-29 18:44
阅读 2479·2019-08-29 12:37
阅读 927·2019-08-26 13:36
阅读 2393·2019-08-26 13:34
阅读 1244·2019-08-26 12:20
