Docker和Kubernetes如何让DevOps更具效力

缩短time-to-makrt对于任何一家企业都至关重要,这直接决定了客户满意度、市场竞争力乃至盈利能力。但在部署应用时,大多数企业内的IT团队都或多或少会遇到Dev和Ops之间的问题,这两个部门围绕着同一个应用工作,但工作方式却截然不同。 很多管理者都在思考如何能让Dev和Ops能够在没有任何“误解”的情况下共同努力缩短time-to-market,也就是DevOps。 下面我们将谈一谈,Docker和Kubernetes如何帮助DevOps发挥更大效力。 传统的DevOps 在传统的DevOps方法中,开发人员编写代码并将其提交给Git存储库,然后检查它在本地和开发环境中的工作方式。 我们会使用像Jenkins这样的CI工具启动代码的构建过程,该工具也在构建期间运行功能测试。如果测试成功通过,我们将更改合并到发布分支中。 运维会使用一些工具为应用程序部署生产准备脚本,并最终将更改投入生产环境(更新版本)。 传统DevOps的问题 第一个问题是运维和开发者使用不同的工具。 »

你准备好持续交付(CD)了吗?

持续交付(CD, Continuous delivery)就是说每次提交代码时立即构建,并可以将构建部署到生产环境中,本文将分享一些持续交付相关的方法和经验。 自动化(Automation) 自动化对于完善的CD管道来说必不可少,我们理应尽可能的用自动化取代手动工作以获得最大利益。 过去,我们的开发团队可能在将代码发布到生产环境之前一般会做测试,其中一些可能是手动的,一些则是自动的。但在持续交付的情况下,每次提交都要进行代码测试,因此最好的办法就是“自动化一切可自动化的东西”,并且不应仅限于开发团队。 软件中所有重要部分的自动化都是必要的—— 测试(Tests) - 单元测试、集成测试、 »

微服务间的通信如何选择

Melvin Koh 如果我们想要构建一个生产就绪的系统,那么必须要权衡所有因素,其中选择微服务间的连接方法更是其中的一个难点。 作者在本文中介绍了一些常见的通信方法,并简要概述了其项目背景以及为何最终选择了RPC。 在决定微服务间连接方法前,我们需要搞清楚两个概念: 架构风格(Architectural Style) 传输协议(Transport Protocol) 架构风格 在使用服务时如何形成有效负载?是有状态还是无状态?我们应该采用REST、SOAP、JSON、XML,还是其他消息格式? 传输协议 我们应该用哪种传输协议?应该采用HTTP、 »

关于微服务CD的5点思考

持续交付是任何软件交付实践的重要组成部分。无论目标部署环境如何,我们都应该设计CD工作流,以便将软件的任何更改投入生产。 对于微服务架构来说同样如此。本文将分享作者Sheroy Marker在架构设计和应用开发中的一些关于CD工作流的思考和经验。 微服务和CD 按照Martin Fowler的说法,微服务架构是“将软件设计一组为可独立部署的服务的方式“。这种方式目前已经成为构建分布式系统/应用的主流;按照Jez Humble的说法,CD(持续交付)是“能够以可持续的方式安全快速地将所有类型的变更 - 包括新功能、配置、错误修复和实验 - 投入生产” »

微服务架构选Java还是选Go - 多用户负载测试

Ivan Nikitsenka 微服务架构允许我们再创建新应用时自由选择不同的技术和编程语言。不过究竟哪种语言更适合我们当下的硬件?回答这个问题,需要搞明白Java和Go编写的相同应用程序之间的性能差异。 先决条件 不采用其他性能增强功能 使用默认框架和库设置的最小配置 没有ORM框架 使用纯DB驱动程序和相同的SQL查询 用于Java的Postgres JDBC 4.2驱动程序和用于Go的github.com/lib/pq 怎么做 使用DB(Postgres)数据存储创建简单的Java/Go REST API应用程序 使用JMeter或类似工具创建负载测试 »