admin – 深圳睿云智合科技有限公司

微服务转型与DevOps

2018年1月27日

分享人：郑云龙睿云智合持续交付产品负责人，在敏捷和DevOps领域有丰富经验的实践，过去作为敏捷和DevOps技术教练向多家大型企业提供咨询和培训服务。微服务转型与DevOps 1 遗留的现状在开始微服务和DevOps主题之前，首先看看在过去我的咨询工作中，对于大部分咨询客户而言，企业会邀请外部的顾问来对团队进行改进，最主要的原因都是由于现有的研发体系和产品团队，难以跟上市场的变化，希望通过外部顾问，通过一些手段来提高产品团队的响应力。敏捷实践亦或是DevOps实践最终的目的都是为了能够快速的交付高质量的软件产品。究其原因，为什么这类客户会有如此大的需求去引入敏捷或者DevOps呢？遗留系统。历史遗留问题与新问题，新需求的持续混合发酵，导致系统的开发效率无法满足业务的发展需求。所以经常会有如上图这种对话。无论是新的需求，还是遗留的Bug都严重受制于遗留系统如果从技术角度来看，对于遗留系统最主要的问题包括：高耦合性，底可测试行，代码质量差，圈复杂度高，并且很难对系统进行优化。而这些东西我们都可以称之为技术债。而这些技术债务的积累最终导致我们的系统越来越难以维护。举个例子，在之前对客户团队进行敏捷技术培训时，尝试在项目中使用TDD，最终的结果是在使用TDD的同时，我们进行了大量的重构，才能保证我们能够顺利的给某一个业务场景添加上相应的测试代码。而技术债不是一开始就有的东西，对于传统单体架构而言，在项目初期系统通常也是易于开发，易于部署，易于测试的。随着时间和项目演进，系统的代码量以及复杂度呈指数型增长，最终导致我们整个项目的交付周期越来越长，同时系统很难进行扩展，并且当扩展时所需要的成本也越来越高。对于新加入团队的成员，也需要花费大量的时间了解业务背景，熟悉应用程序的业务，配置本地开发环境等等。这些看似简单的任务，往往需要花费大量的时间。同时对于传统单体架构随着时间和项目的演进，尝试引入新技术或者对现有技术框架进行改进的成本和风险也越来越高。而对于传统的SOA架构？如果用直白一点的话来说，就是专注于使用ESB来集成企业内的各个单体应用。而往往导致的结果是两个大的中心化，技术的中心化，以及流程的中心化。由于EBS通常基于特定的技术栈，并且使用了中心化的标准个规范，使得业务难以根据业务场景去选择合适的技术。而ESB也往往嵌入了大量的业务流程，所以导致任何服务的修改都需要进过复杂的流程，修改系统的工作量不减反增，维护成本和产品成本也呈非线性增长。 2 什么是微服务架构通常而言我们对于微服务并没有一个准确的定义，但是我们可以认为，微服务就是我们去以正确的姿势去实现SOA。对于微服务通常具有以下特性：独立进程，独立部署，独立技术以及独立团队。对于每一个服务而言都是以开发一个小的独立的应用系统，并且每个服务都是运行在自己的进程中；这些服务围绕业务功能进行构建，并且能够独立的部署和发布；同时服务与服务之间可以使用不同的技术语言以及存储技术；而对于每一个微服务都是由一个充分独立自治的团队进行端到端的管理，从开发，构建，部署，上线运维。并且这些服务之间通常采用一些轻量级的通讯接口包括像Rest API以及消息队列而对于每一个微服务而言我们都可以根据其不同的业务场景去选择适合的技术，并且这些服务之间可以有不同的发布节奏除了技术上的去中心化，在团队组织结构上，每一个微服务团队都应该具有和当前业务功能开发所需的全方位技术，及所谓的全功能团队。这些团队围绕着各自的业务管理相关的服务。相比于传统的通过组件的方式拆分团队，微服务团队可以端到端的完成特性交付，减少由于将特性分配给多个团队而导致的沟通问题，系统集成问题，能够更加快速的交付所需的特性，减少等待时间。同时微服务架构能够帮助我们快速的开辟新的渠道，助力企快速获取市场机会。刚才谈了很多关于微服务本身的特性，以及能够为我们带来的好处。但是事无好坏，对于任何一家公司和组织，在转向微服务之前都应该明白它为我们带来的潜在的挑战。微服务化带来的挑战？运维的挑战、质量保证体系、分布式系统的复杂度首先我们来说关于质量的部分对于任何传统意义上的测试保障体系，我们通常会通过单元测试，API测试，系统集成测试，以及其他的非功能性测试，诸如性能测试，安全测试等来保证我们软件交付的质量。在敏捷测试实践中我们通常以测试金字塔的方式来评估我们现有系统的自动化测试水平以及合理性。那在微服务中呢？刚才我们已经说过，微服务是一组独立的去中心化得服务，服务和服务之间必然存在相应的依赖关系。在这里我们仿照敏捷测试金字塔的方式将微服务的质量保证体系划分为3层:服务内，服务间，以及服务集成。相比与过去的软件质量保证体系，我们增加了契约测试来保证服务和服务之间的依赖，确保各个服务是能够独立的进行演进升级的。对于契约测试目前包括像Thoughtworks开源的契约测试工具Pact以及Swagger这样的工具都能够帮助我们将契约测试添加到我们的质量保证体系中。当然对于所有的自动化的质量保证过程，我们都应该将他们纳入到CI流水线中，通过自动化的方式来保证我们每一次代码变更都是能够满足质量要求的。那对于运维体系而言呢？运维体系面临的挑战 1，部署环境的多样性，对于传统团队的Ops人员，他通常都是接触一些固定的技术栈相关的运维和管理工作，但是在服务下，每一个服务都都可能采用不同的技术，数据库，以及中间件。那对于Ops人员而言所需要面临管理和运维的环境的复杂度和难度也随着服务化得进程变得越来越困难 2，对于公司而言从开发，测试到部署上线，我们通常需要使用大量的服务器资源来保证我们各个环节的部署环境需求。举例来讲，在敏捷当中我们通常会有Dev环境，UAT环境，Prod环境去提供软件交付过程中各个阶段的部署需求。但是微服务之后我们可能有几个，几十个甚至几百个不同的服务，而这些服务都需要相应的部署资源，同时如何保证各个阶段的环境一致性问题 3，CI维护成本暴增，在过去我们通常会花费通常一个迭代的时间来搭建我们项目的CI基础设施，但是现在随着服务数量的增加我们管理和配置Jenkins的成本也越来越大 4，除此之外包括，日志，监控，弹性，高可用都是我们在微服务转型过程需要面临的挑战。如何解决充分授权团队在微服务下我们希望每一个团队都是能够充分独立和自治的。但是往往对于企业而言对于基础设施环境的管控要求其实非常高，包括像网络，安全等等。所以往往对于一个团队想要获取一个服务器资源通常需要复杂的审批以及配置过程。而通过引入像Rancher这样的轻量级的容器化管理平台，我们可以将底层基础设施的管理问题交给专门的运维团队来进行处理。这些基础设施可以是物理机，IaaS，甚至是容器集群。并且将这些资源按照环境的形式分配给不同的团队，充分授权团队，管理自己的所有的开发，构建与部署环节。基础设施代码而对于持续集成流水线，以及持续交付流水线的管理和配置，Jenkins2.0通过Pipeline As Code的方式通过编写DSL来帮助我们实现全面的基础设施及代码的要求。在代码库当中及包含源代码src，也包含我们的环境准备过程Dockerfile以及环境定义docker-compose.yml. rancher-compose.yml. 同时我们将我们的持续交付流水线也通过Jenkinsfile的形式保存在源代码库中，那么只要我们获取了软件仓库的代码，就能够获取支撑我们软件交付各个阶段的所有物品，包括源代码以及运行时环境。并且对于任何代码或者环境的变更都能够通过持续交付流水线进行持续的验证和反馈同时Rancher也提供了内置的监控功能：包括主机以及容器。通过Catalog我们也能快速的搭建ELK的日志分析平台以及其他的监控服务。通过服务容器化，以及引入诸如Rancher这样的容器管理平台。我们可以使我们的研发团队更加专注于软件架构以及环境架构的设计，而将一些其他的运维和管理工作交给容器管理平台来管理。能有效的减少我们在DevOps实践当中的成本，包括人员能力以及自动化能力的要求。同时对于微服务团队而言，我们基于持续交付流水线能够使软件交付各个阶段的人员能够有效的协同工作，保证我们能够又快又安全的交付软件，每一次代码变更都能够产生一个可工作的软件（当然前提是这些人都是属于同一个团队）所以对于转型微服务而言，我们需要明白持续交付以及DevOps文化是支撑我们微服务转型的一个重要手段。我们需要有独立自治的全功能型团队，通过引入虚拟化技术，容器化技技术，以及相应的管理平台来减少我们部署和运维的复杂度。并且通过更加完善的质量保证体系来确保我们的服务能够确实的去支撑我们的软件交付质量。总结就像开篇说的一样，“微服务可能是实现SOA的最正确的姿势”，它实际上是我们软件交付领域大量优秀实践的一个集合。同时微服务是不银弹，在引入微服务后我们同时需要面对更多复杂的问题。通过引入容器化，以及容器化管理平台能够减少我们在转型微服务过程中的大量成本；通过小步尝试，积累经验和能力，能够帮助我们在微服务化转型中走的更加顺畅；同时根据不同的业务模式选择不同的微服务重构模式能够帮组我们能够在解决现有问题的同时来全面提升我们整个产品的响应力；最后一张图，简单总结了一下微服务中关于实践与设计模式的概览，希望能够对大家在服务化转型中提供帮助；最后在准备这次分享的过程中我准备了一些例子，包括Jenkins2的容器化，以及基于Jenkins2和Rancher实现端到端的持续交付过程： https://github.com/yunlzheng/rancher-jenkins2 https://github.com/yunlzheng/jpetstore-6 有兴趣的同学可以进行参考，当中不完善的部分也希望能够提供反馈，能够进行相应的改进。...

深入理解Kubernetes网络策略

2018年1月27日

分享人：梁文智-睿云智合研发顾问时间：2017-7-20 当我们逐渐向着微服务、云原生迈进的时候，传统静态的、相对简单的网络安全策略开始显得吃力。 Kubernetes 的 Network Policy 特性正是来解决这个问题的。在刚刚出炉不久的1.7版本中，该特性也被扶正成为GA。让我们来一起看看 Network Policy 是什么，能为我们做什么，以及是如何实现的。 CNI Kubernetes 对网络做了较好的抽象。它将对网络的需求交给外部的组件完成，也就是 CNI driver。 Pod 的网络必须满足以下三个需求： 1 所有 Pod 之间无需 NAT 即可互通 2 主机和 Pod 之间无需 NAT 即可互通 3 Pod 自省的 IP 地址和之外部看到该 Pod 的地址一致 CNI 对网络的实现做了详细的定义。CNI 的实现可以被分成三种： 1 3 层路由实现 2 Overlay 实现 3 2 层交换实现现在比较常用的 CNI 实现有：Flannel、Calico、Weave。 Flannel 通过 VXLan Overlay 来实现跨主机 Pod 网络， Calico 则完全通过 3 层路由来实现了跨主机的容器网络，Weave也是 Overlay 的实现。什么是Network Policy 随着业务逻辑的复杂化，微服务的流行，越来越多的云服务平台需要大量模块之间的网络调用。传统的单一外部防火墙，或依照应用分层的防火墙的做法渐渐无法满足需求。在一个大的集群里面，各模块，业务逻辑层，或者各个职能团队之间的网络策略的需求越来越强。 Kubernetes 在 1.3 引入了 Network Policy 这个功能来解决这个问题。这些 Policy...

度量驱动的DevOps转型

2018年1月27日

分享人：郑云龙时间：2017-1-17 睿云智合持续交付产品负责人，在敏捷和DevOps领域有丰富经验的实践，过去作为敏捷和DevOps技术教练向多家大型企业提供咨询和培训服务。虚拟化，容器化，云计算，自动化为DevOps运动提供了底层技术支持，新的工具链和技术栈的采用进一步降低了DevOps的技术门槛，越来越多的企业纷纷开始自己的DevOps转型之路，然而…… ▪ DevOps以及企业DevOps转型的现状 ▪ 为什么我们需要在DevOps转型中强调度量 ▪ 如何实现度量驱动的DevOps转型 ▪ DevOps转型中的其它实践 Wiki上讲：DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例（这个是目标）透过自动化“软件交付”和“架构变更”的流程（这个是方法）来使得构建、测试、发布软件能够更加地快捷、频繁和可靠（这是结果）。所以对于企业来说的真正价值则在于通过团队间协作关系的改善，整个组织效率的提升的同时，可以有效降低伴随频繁变化而带来的生产环境风险，从而提升企业应对市场变化响应力。根据2016 DevOps调查报告显示。成功实施DevOps组织可以更快的去适应整个市场环境的变化，同时能够更快的做出调整。拥有相比竞争对手拥有更加高的部署频率，更快的故障恢复时间，更低的变更失败率以及以及更短的需求交付周期。然后当企业大量的采纳并使用这些新的工具链之后，我们并没有看到我们所交付的软件真的如同DevOps的目标一样，能够真正的实现软件快捷，频繁并且可靠的交付。 DevOps不是盲目的使用新的工具链和技术栈，通过自动化部署流水线的方式，将低质量的代码频繁的部署到运行环境。目前实施DevOps转型的传统企业，通过引入自动化确实能提升在软件交付的某些环节中的效率，但是却很难去提升软件的交付质量，依然引入独立的测试部门进行大量的系统测试来确保软件的质量，同时企业也很难度量持续交付和DevOps实施的效果。所以目前大部分企业基本上是把自动化当做DevOps在做，把自动化部署当做持续交付在做，而很少去考虑软件交付流程的整体性优化。自动化是实施DevOps的先决条件但是并不能真正的帮助企业跨越DevOps转型的鸿沟的银弹。而对于DevOps的成功转型而言，我们需要做的是持续的对我们的软件交付过程进行优化，发现软件交付过程各个环节中存在的瓶颈并持续改进。 You Can’t Fixed What You Can’t. 而数据和度量则是帮助企业去发现DevOps转型过程中的瓶颈并且做出改进的关键基础。在开始时我们说从Wiki上看，DevOps会主要设计到3个部分：目标，方法和结果。所以从度量的交付上看我们需要从两个方面去度量我们的DevOps转型。哪些度量指标是能够支撑企业判定DevOps转型结果。而哪些是能够去评判软件的交付过程，并且用于发现交付瓶颈的。根据2016DevOps报告显示，目前度量企业DevOps转型是否成功的最终结果性关键指标包括：吞吐量指标：部署频率，变更交付周期。稳定性指标：变更失败率，问题平均恢复时长（mean time to recover）。吞吐量即敏捷性，确保企业能够适应市场的变化，并且快速做出反馈。稳定性，即高质量。相比于传统的IT服务流程绩效指标ITIL而言，DevOps更加关注结果性指标，即客户价值。就好比我们做软件交付和外卖小哥其实很像，可以评价一个产品是否优秀更多的是看交付效率如何，质量如何，并且是不是能够满足我的预期的？这两种截然不同的度量方式本质就是OKR和KPI的区别： OKR基于目标和关键成果，促使我们思考，沟通，每个人都知道什么是最重要的；并且能让团队所有人共同的为某件事而努力。所以对于基于OKR驱动的DevOps可以确保参与软件交付过程中的所以角色围绕具有通过的目标，并且为了这些共同目标去尝试新的技术和方法。而KPI理论则避免按照SMART标准制订，有些事情值得去做，但在做出来一部分之前无法测量因此无法制订目标。KPI 还有一个更严重的问题，那就是为了完成可测量的目标，有可能实际执行手段与该目标要达到的愿景正好相反。 KPI使得团队使劲往前走，而OKR则确保团队能够往正确的方向走。而在软件交付过程中，开发，测试，运维都有着不同的考核标准。所以KPI能够团队各个成员使劲的按照各自的目标走，而OKR则确保团队能够一起往正确的方向走。 DevOps需要的是整体性的优化，当你选择自己企业内部的度量标准时，请问自己两个问题：为什么需要度量这个指标？从这个指标中我们能学到什么？根据DevOps 2016报告高效的IT组织与中等和低效的IT组织之间在DevOps最终结果性关键指标存在则显著的差异。 DevOps的最终结果性指标能够帮助企业去衡量和评判DevOps转型的结果。当然除了结果性的指标去验证DevOps转型所起到的作用以外，我们还需要持续的度量其他的数据去帮助我们发现在软件交付各个阶段的问题。包括从需求管理，源码管理，构建过程，测试过程，部署过程，发布，配置管理，监控等各个方面，这里我们列举了在各个过程当中可能需要的一些度量数据。其中比较典型的包括通过对需求管理进行度量，我们可以知道从需求到需求部署上线的变更交付时间。在CI过程中我们持续的去获取相关的过程数据，如构建次数，构建频率，构建时长，成功率，平均恢复时间等可以帮助团队去判定研发团队是否能够做到小步提交，频繁提交，并且当发现问题之后能够快速的恢复。除此之外，低质量的，高复杂度的代码也会使得软件交付效率无法得到有效提升，所以我们需要持续的获取代码质量相关的数据，持续改进代码质量等等。所以对于度量驱动的DevOps转型而言，我们需要持续的去获取在软件交付各个阶段所产生的数据，以及软件部署上线之后的监控数据，用户行为数据等，并且形成对团队所有人可见的DevOps可视化看板。而产品/需求管理人员，则可以根据DevOps结果性数据去评价在过去一段时间内DevOps实施所产生的效果，从过程性数据中去发现交付过程中的瓶颈，根据用数据以及线上监控数据去评价软件产品是否如预期的一样产生相应的价值，如果没有，是否应该做出及时的调整。除了通过自动化的方式去构建软件交付的端到端流程提升软件交付，并且持续的获取软件交付的各个阶段所产生的数据以外。我们还应该在软件交付流程中去设置相应的门禁机制，去让不满足质量要求的构建快速失败。在实践当中，根据软件产品的体量的不同完整运行端到端自动化的过程可能会非常长。所以对于研发团队而言，持续部署流程所产生的反馈周期过长，不利于研发团队快速发现和解决问题。 1 基本CI流水线频繁执行，由代码提交触发，包含构建，单元测试，集成测试，代码静态扫描，部分自动化验收测试等（端到端运行周期短）。 2 FOR TEAM：全量流水线每日定时多次触发，包含构建，单元测试，集成测试，代码扫描，全量的自动化验收测试，部署，部署冒烟测试等等（端到端运行周期长）。 3 FOR QA：手动指定版本部署，手动触发。通过分层流水线，在满足快速反馈的原则的同时，又能持续的对软件进行集成和测试。同时在流水线当中通过引入质量门去控制代码质量，避免技术债务的积累。当然对于历史遗留系统而言，通常会存在大量的历史债务，这时候我们可以将当前系统的代码质量作为基线标准，同时针对新增代码设置质量门控制，包括新增代码的代码风格，复杂度，测试覆盖率等。通过可视化流水线将将持续部署流水线的构建过程向整个团队进行展示，让所有人都知道当前的项目构建状态以及进度，如果又构建失败了，成员之间也可以相互提醒尽快修复流水线的失败。持续的获取过程有效性数据和质量有效性数据为团队提供可视化看板。除了门禁机制以外，质量内建也是团队成功实施DevOps的关键因素，通过在软件交付的各个阶段建立自动化的保障体系可以使团队能够尽早的发现和解决发现的缺陷。对于度量驱动的DevOps转型，通过自动化部署流水线有效提高软件交付的效率，通过质量内建确保软件交付的质量，通过对过程性数据的持续收集和分析发现交付过程中存在的瓶颈，通过对软件产品和用户的线上数据获取反馈并且及时作出调整，通过结果性数据去评价团队的成效。最后对于企业DevOps转型而言： Automation 自动化是实施DevOps转型的先决条件，自动化一切可以自动化的，降低部署和发布的难度。 Measure 通过建立有效的监控与度量手段来获得反馈，推动产品和团队的持续改进，支持业务决策。 Lean 协作文化，自动化，和有效的反馈，这些实施是个长期的过程，需要以精益的方式小步快跑，对过程与技术进行持续改善。 Culture OKR目标和关键成果驱动建立具有跨职能协作文化和共同目标的一体化团队；这是DevOps运动的根本！ Sharing 不同职能、不同产品之间分享开发和运维过程中的想法，知识，问题，以及失败经验，共同提升能力。 Q&A Q：基于Jenkins的CI/CD不同用户是怎么管理的？权限怎么控制的？ A：在DevOps实施里面提倡充分授权团队，所以在基础设施自服务的基础上让团队有自己独占的Jenkins Master能够有效的减少权限控制此类问题，同时可以避免不同团队之间构建任务的相互影响；如果是共用JenkinsMaster，Jenkins有权限控制的插件可以控制用户的权限。 Q：刚才你介绍的CI整个交付流程，每个细节都需要花大量的时间和精力去开发和实施，如果公司团队很多，如果分配自己团队的时间，时间少了自然达不到效果。 A：在实施DevOps转型过程里面，可以先尝试试点团队，通过试点团队去完成DevOps工具链相关的技术选型，在工具链成熟的情况下向其它团队推广。 Q ：请问你们有DevOps的自动化运维平台吗？可能是一个Web页面，把DevOps相关的流程和工具集成在上面，方便管理的同时也方便运维开发一体化操作。这个平台可能还包括全链路检测系统？ A：目前我们公司做的基于容器持续交付平台主要就是解决此类问题，通过流水线来组织工具链，同时对相关的环节进行度量，为避免广告嫌疑就不便多说。 Q：你们在这个过程中怎么做沟通管理，以防止因为这造成的对需求理解的偏差等问题？ A：这块更多是团队的组织结构的问题，有兴趣可以尝试通过看板方法，团队的各个角色都会基于看板完成迭代的开发，通过看板可以帮助团队成员之间的沟通和需求确认。 Q：因为很简单，持续集成持续交付，快速迭代，小步快跑，稳扎稳打，这些都有所有的理论最后都回归到代码，所有的变更都回归到本源代码的变更，如何保障所有的变更无遗漏，如何保证每一次任务都在正确的代码基准线上进行，如何出了问题快速反馈到研发第一线，及时终止问题的蔓延？ A：这块其实主要的方式就是基于持续部署流水线的方式，上面分享的时候有提到。通过将流水线通过自动化流水线的方式进行控制，在任何阶段出现问题都应该让流水线失败（门禁），另外出问题不怕，快速解决问题是关键，对于流水线最好可以设置Webhook实时触发，可以确保当问题出现后，问题代码的域可以关联到最近的一次提交。 Q：请问你们容器发布是如何自动区分开发、测试、正式等不同环境的，是否需要人工介入修改应用访问关系和启动环境变量？ A：目前我们自己持续交付平台对接不同的容器运行环境（目前主要是Rancher），团队会对环境进行分类管理，流水线中进行容器部署的时候选择相应的环境即可；另外由于主要是基于容器在做，所以也对容器镜像的不同状态也进行了划分，并且在多个Registry实例之间进行了流转，物理隔离了开发，测试以及发布状态的容器镜像。人工介入的部分主要是控制镜像状态的变化这块。 Q：Jenkins的Pipeline和普通的Project都可以支持流水线，2者有区别吗？ A：主要解决的问题就是当构建出问题的时候如何快速定位问题，假如在流水线线中涉及8个阶段，如果只是在一个Project中实现，需要开发者花很多时间定位；如果是Build Pipeline的话，则可以很直观的知道问题是发生在什么阶段。...

睿云智合金融科技说：战略和技术变革下的金融云趋势

2018年1月27日

近年，金融市场竞争逐步加剧，尤其是移动支付、众筹、P2P、量化投资、智能投顾等新型金融服务的推广和应用，将整个金融行业带入史无前例的科技力量之争。战略家们预言，不久的未来，所有金融业务必将由科技驱动，金融科技领域将成长出更多明星企业。在波士顿、麦肯锡等权威咨询机构近期发布的全球金融科技发展趋势报告中，金融科技被进一步划分为几大技术领域：人工智能、大数据、移动物联网、云计算、区块链。其中，最为基础的核心技术，仍是云计算。云计算作为一切应用系统交付和运营依赖的基础架构平台，能否灵活、高效支撑起融合了各种创新技术的业务软件生产与运维，是传统金融企业推行金融科技变革必需面对的首要挑战。 2016年我国金融云IaaS市场整体规模为43.4 亿元，预计2017 年将达到63.0 亿元，同比增长45.2%，且随着云市场的发展，PaaS也将逐步成为金融科技平台建设刚需。之后，金融企业IT架构无一例外，都将构建在云计算技术缔造的基础平台之上。近来容器技术高速发展，催生“云计算2.0时代”，为传统金融企业应对金融科技云计算应用带来新的机遇和挑战。从2015年开始，国内主流金融机构已经陆续有先行者尝试引入容器新技术，提升企业云平台服务能力。例如： ——国内首家面向市场推出容器云服务的综合金融集团：中国平安； ——国内首家将基于容器的PaaS平台落地的股份制商业银行：恒丰银行； ——国内首家将容器技术在CI/CD、微服务、混合云管理等应用场景予以全面实践的金融机构：富德生命人寿； ——国内首家将基于容器的DevOps平台在生产环境进行部署实施的保险企业：民生保险； …… 这些金融企业无论IT亦或业务发展，在各自领域均走在行业创新前端。他们革故鼎新背后，提供技术支持的团队，正是推动传统金融企业提升云计算科技水平、实现IT为业务赋能的金融科技公司——睿云智合。深圳睿云智合科技有限公司（简称睿云智合），创立初期主要专注于金融行业创新业务管理与技术咨询。在积累了多年金融行业数字化业务转型、相关创新技术引进服务丰富经验和客户资源后，于2015年组建起专业云计算技术服务团队，率先将容器技术引进传统金融行业，并迅速在业内树立起客户标杆和遥遥领先市场的成功案例。面对全球科技革新的迅猛趋势，金融行业将如何发展？在当下和未来之间，金融科技企业该如何平衡自身发展与行业趋势？我们与睿云智合来一场深刻探讨：聚焦金融科技如何帮助传统金融企业实现数字化业务转型的战略目标、以及金融云市场未来的发展趋势。 CSDN：金融与科技的关系历久弥新，尤其近年受”互联网＋”战略影响，科技金融呈现爆发之势。在转型创新的过程中，金融科技主要为金融企业解决哪些核心问题？睿云智合：过去，金融企业依靠政策优势、稳固的第三方获客渠道关系，以及与客户间不对称信息交互方式，保障了业务“保守、稳定“的发展格局。现在，互联网巨头和诸多新生科技力量渗入金融领域业务竞争，”互联网金融“一夜之间打破了整个金融行业的平静。强大的客户数据基础、快速高效的移动互联客户沟通方式、更多方便触发客户直接交互的销售场景，都成为了科技新金融天然数字化业务竞争优势。所以但凡讨论金融业发展，无不聚焦于金融科技、数字化转型。追根究底，其核心就是要解决IT赋能，支持业务向“以客户为中心”经营模式实现转型的问题。在数字化业务领域，谁能抓住业务与创新技术更多结合点，谁就可能掌握更丰富、更灵活、更优惠的获客方式及运营能力，从而占据竞争高地。 CSDN：在睿云智合服务过的金融行业用户中，他们主要面临哪些挑战？如何在实践中解决这些挑战的？睿云智合：在过去几年互联网金融的探索实践中，传统金融企业用户数字化业务创新，常常面临企业IT架构陈旧、应用系统交付效率无法满足业务发展需求的困境。因此，改造旧有系统架构，将业务应用系统“云化”，打造更为高效顺畅的软件生产与持续运营平台，逐步成为诸多金融机构IT基础能力建设的重要课题。一些有技术能力、资源实力的大型金融机构，看到金融云市场未来的发展趋势和市场机会，不仅从自身需要考虑，对新一代云计算架构平台投入，更借助先行者的技术及资源优势，向同业进行云计算乃至更多IT能力的输出。例如我们第一个客户，就是在金融行业最早实现容器云服务的平安科技。他们面向市场推出的平安金融云项目，除了将容器云平台快速对接已有IaaS平台，提供容器云基础设施资源全面运营管理能力，还实现了为租户提供开发测试环境的自助服务，为外部用户CI/CD流水线提供容器运行时环境，实现持续交付等功能。此外，平安还逐步将自身一些成熟的企业应用，通过金融云开放，面向同业进行推广。据平安金融云透露，目前已经签约了近200家金融机构用户，这无疑是目前市场上金融企业自身IT能力转化为行业输出的成功典范。另一个具有代表性的，则是将容器可应用场景全面实践的富德生命人寿。在引进容器技术之前，富德生命人寿已将核心业务系统解耦为六十多个应用模块，并尝试系统架构的微服务化治理。这些应用以自研为主，所以随着系统架构改造，面临如何大幅提升软件生产交付过程的自动化管理水平，以及在支撑互联网应用和大数据应用为主的混合云架构下，如何安全可靠地实现应用持续运帷的困境。我们为富德生命人寿设计了基于容器的软件持续交付和系统持续运行PaaS平台，将混合云管理、CI/CD及开发测试环境自动化、DevOps微服务部署运维等方案均逐一进行了落地验证，项目成果最终为富德生命人寿基于容器技术的应用模块快速交付、部署与升级，以及对大数据集群的自由调度和弹性伸缩，提供了全面有效的解决方案。提到基于容器的PaaS平台建设，不得不说说银行业的先行者恒丰银行。基于银行业务场景和银行业的特殊需求，我们为恒丰银行定制开发了鉴权认证、资源管理、应用编排、弹性伸缩、日志收集、监控告警以及镜像仓库可视化管理等一系列PaaS平台的微服务模块，实现了容器云平台对多租户隔离环境的集中管理。其中，隔离环境分别对应到某个租户的特定网络，单个网络内部流量采用睿云智合(Wise2C)实现的扁平化网络方案，网络之间流量由外部防火墙控制。由于客户还存在跨网络部署应用栈的需求，因此存储必须要基于租户的粒度，可以实现跨环境共享。我们也为此设计了合适的方案。实际上，借助容器技术大幅提升云平台服务能力的案例还有很多，随着这些项目逐一落地并产生更多的项目成果，我们相信它很快将会成为一个普遍的行业需求。 CSDN：睿云智合在金融垂直领域拥有丰富的行业经验，是否会将其融入到产品服务的设计中？相关的产品在哪些方面具备亮点，是否已经有成功案例？睿云智合：过去，”以客户为中心“（CRM）的经营战略在金融机构更多只是一句口号，因为客户信息积累规模和质量均不足，客户接触点稀少且频度低，CRM理念中强调的客户价值持续挖掘很难体现到业务实践中去。到了数字化业务竞争时代，获客方式和服务模式改变，越来越多客户数据洞察机会、新客户接触点出现在企业面前，客户洞察结果及相关应用变得日益丰富。令互联网企业获利丰厚的CRM应用如客户忠诚度管理、精准营销、多产品叠加等，对金融企业终于不再是一句空话。容器技术贯穿底层基础设施资源管理、上层应用生命周期管理，是一个使用场景极为丰富、回报价值很高的新兴技术。但容器技术应用场景复杂，在持续发展变化过程中具有波动性，使过去一贯保守、且依赖第三方技术服务的金融企业，在计划将之快速引进落地时存在阻碍。他们需要付出更多学习时间、谨慎选择新兴第三方服务商。基于此，睿云智合决定用自身经验帮助金融企业实现转型。截止目前，睿云智合累计服务过的金融机构近40个，已经落地的容器项目客户案例超过十余个，其中近三分之一的客户已将容器技术应用于生产环境实践，在IT基础能力提升方面取得了显著效果。在此过程中，睿云智合技术团队除了在实施服务能力方面得到了充分的锻炼，更是在大量实践基础上总结输出了自主容器云平台产品WiseCloud，在前述项目案例中提及的诸多重要功能均已在该产品中完整体现。 WiseCloud支持Docker、Kubernetes等主流容器调度引擎，也引入Rancher等企业级容器管理平台，提供开发、测试、发布、持续运营等容器化应用的全生命周期管理。面对多容器集群管理平台，WiseCloud能提供完善的容器管理平台基础性服务，包括容器网络，存储服务等，对各种容器集群平台的资源进行统一抽象。此外，WiseCloud未来将逐步支持行业应用架构和接口标准/规范，比如常用行业应用中间件、基于微服务的行业应用商店、已开发好的行业应用SaaS服务等。睿云智合智合产品架构图目前WiseCloud已经在客户案例中成功落地，就是上面提到的民生人寿保险容器应用云平台。在金融行业，这是已知第一个将容器技术应用于关键业务系统生产环境的案例。项目实施至今已近1年时间，民生保险的IT团队从研发到运维，已经适应容器化环境下、高度自动化的DevOps体系，也日益体会到高效开发运帷一体化的好处。目前，民生保险正在内部持续完善该体系的细节管理规范，并计划逐步将所有IT系统迁移到容器云平台。 CSDN：目前以容器技术为核心的金融云服务市场竞争非常激烈，其中不乏一些知名度高的强劲对手，与他们相比，睿云智合的优势在哪里？睿云智合：金融企业在新兴数字化业务领域的竞争，必须依赖大量科技力量创新，在产品、客户营销模式、服务管理方面建立优势。要快速建立这种竞争优势，现阶段传统金融企业的IT基础架构、治理模式必需顺应趋势进行变革，这正是我们金融科技技术厂商的机会。然而传统金融机构的IT架构与IT准则，远远复杂过互联网企业。甚至一些金融机构的IT环境，有各自迥异的特征与个性化需求，这使得由互联网企业服务领域，转向金融企业用户市场的容器技术服务商难以适应。睿云智合的前身便是专注于为金融企业提供数字化业务转型以及CRM战略导入的咨询机构，我们从最早帮助金融机构实现数字化业务转型开始，已专注于服务金融客户多年，在金融企业用户需求把握和产品设计方面，有得天独厚的行业背景优势。在组建技术服务团队的过程中，我们注重选择和培养那些具备丰富企业服务、特别是金融行业背景经验的技术人员，在快速积累行业客户项目实践中，逐步巩固和提升我们的专业服务能力。这种专业性和对行业用户的深度理解，也体现在了睿云智合容器云产品的规划设计中。 WiseCloud平台能同时支持多种主流容器集群编排调度管理平台，在帮助金融企业用户规避容器底层框架技术路线选择风险上，带来很大灵活性，我们提供给用户充分技术保障。 CSDN：睿云智合聚焦金融行业的科技服务，可否展望一下关于金融科技领域未来的发展方向，以及睿云智合相对应的公司战略是如何规划的？睿云智合：现在金融企业需要管理的应用系统最多上百个，未来，一个大中型金融机构需要管理的应用系统将成千上万！作为企业市场竞争最依赖的营销类系统，产品管理、客户管理、精准营销将成金融企业重点投资建设应用项目，它们决定了企业实现差异化经营的竞争力。在金融科技充分发展的未来，金融机构业务模式和组织形态都将发生巨大变革，大量的运营管理工作将由越来越多的技术手段来替代。届时，金融企业诸多应用系统将趋于标准化，智能化，粒度更细的微服务化。不难想象，未来金融企业用户市场上，众多中小机构需要成本控制和差异化经营，在有限IT资源投入条件下，具有行业属性的SaaS或云端应用商店，将使他们采购海量应用系统时大大受益。因此，未来金融云市场必将以IaaS、 PaaS、以及具备行业属性的SaaS和应用商店等多种形态呈现。在睿云智合的发展规划中，除了在PaaS层提供完备的解决方案，公司还将进一步谋求向应用层发展，通过自研及整合优秀第三方金融科技行业应用、金融企业同业输出应用，搭建这一垂直领域的行业应用商店或SaaS超市，为更多中小金融机构从云端获得快速、便宜的创新技术与业务服务提供帮助。现阶段，睿云智合主要致力于将公司基于容器的云计算技术服务、及PaaS平台产品（WiseCloud）推向更多的金融客户，帮助他们及早打造支撑未来金融科技发展战略的云计算基础平台。未来，我们则将继续秉承公司多年理念，帮助金融机构实现“以客户为中心”的数字化业务转型和创新科技引进，伴随客户成长，将产品和服务线向金融科技更多领域扩充和延伸。...

容器在企业环境落地的实施路径和关键挑战

2018年1月27日

一. 容器在企业的落地场景 6月4号DockerOne Container 大会上，包括来自Docker 平台产商和Docker 用户的众多嘉宾都分享各自的容器实践, 以及未来的发展趋势, 其中Rancher Labs 的CEO 梁胜博士分享容器要企业落地的主要场景和实施关键，梁胜博士谈到了容器在企业落地主要四种场景: 另外，梁胜博士认为，容器在企业落地，关键不是为服务架构，容器云的建设, 才是在企业落地的关键二. 容器在企业的落地实施路径结合Wise2C 过去在金融保险行业容器实践，选定一个能在企业落地场景非常重要，但同时，也需要注意容器在企业的落地，需要结合自身实际情况有一个逐步推进的过程，要找到一点适合自己的容器实践路径。下图是我们分析了金融保险IT的现状，提出一个保险行业推进容器落地的实施路径: 容器过去三年发展非常迅速，但到目前容器主要的用例还是软件的开发测试环节，Docker 容器技术带来的一个划时代的价值贡献就是解决了软件和环境的依赖问题，所以docker容器出现后在软件的封装和分发应用方面有很多使用案例: 1 推进容器在企业的落地，首先可以考虑在软件开发和测试环节，利用容器技术，提升和改进现有软件研发流程，构建或者改进现有的CI 系统. 2 其次，可以考虑将传统应用容器化，在部署和运维环节解决现有系统的痛点，不要对容器技术过度定位，在网络和存储等方面尽量利用现有主机网络，存储或者底层IAAS 提供的网络，存储服务。例如考虑是用容器技术来简化复杂应用的部署，利用容器的服务编排能力，实现应用的一键部署. 上述两个场景，是初次接触容器技术企业重点考虑的方向 3 对正在规划建设私有云的企业，可以考虑容器云的建设方案。过去虚拟化或者IAAS平台的建设，解决的是虚拟机等基础设施资源的快速部署和供给问题，对外提供的仍然是计算，网络和存储的基础设施服务，但企业内部的开发，测试团队或者业务部门，往往需要的是一个开发测试环境，业务系统环境，是包括基础设施以及相关应用等. 容器云可以提供更细粒度的资源供给同时，可以交付整体应用环境. 符合云平台用户的最终使用需求 4 在熟练是用容器和有良好容器使用实践的基础上，企业构建基于容器的轻量级PAAS，构建企业应用商店，全面监控和管理应用的生命周期。相比传统的PAAS平台，基于容器的PAAS平台可以为开发和运维团队带来更多的灵活性和控制力. 5 如果企业在维护和使用庞大的复杂的单体应用，在推进应用微服务架构转变时，可以利用容器管理平台来管理微服务的复杂性。一个复杂应用拆成多个微服务后，带来微服务的管理复杂度，利用容器管理平台，可以为微服务提供资源调度，服务编排，服务监控，服务高可用以及服务发现等平台服务. 降低微服务的管理难度. 三、容器在企业的落地的挑战和风险目前，容器在各个场景都有广泛的使用案例，但是作为刚出现的创新技术平台，如果对docker容器技术没有很好地掌握，或者过度定位，要把容器在企业落地会存在较大风险. 这些风险包括 1 容器技术的成熟度和对容器的过度定位带来的技术风险。目前容器在安全隔离，网络和存储等方面还不太成熟，Docker 技术发展非常快，Docker 技术生态圈也在快速的推出各种网络和存储方案。企业客户往往缺乏对这些新的方案实际使用经验，很难选择合适方案。另外很多Dokcer 平台和生态系统厂商容易对容器技术过度定位问题. 2 团队缺乏容器相关实践锻炼，缺乏对容器的正确理解，容易将容器的用法和虚拟机进行比较和对照，在应用封装，部署，运维和安全管理等方面不能正确使用容器，充分利用容器带来的好处。例如, 对于容器的使用，企业IT团队容易犯的错误是把容器和虚拟机进行对照. 再用部署时，往往不会将应用系统拆分应用程序，数据和配置，打包进容器运行，因此封装，部署和运维等方面不能正确的形成一套机制来充分利用容器带来的便利....

睿云智合@CCTC 2017 中国云计算技术大会

2018年1月27日

国内云计算技术领域最专业、影响力最大的盛会———中国云计算技术大会CCTC 2017，5月18-19日在北京朝阳门悠唐皇冠假日酒店盛大召开。来自海内外的超过60多位讲师、以及2000多位云计算专业开发者和相关从业人士参与了此次盛会。 CCTC云计算技术大会，睿云智合展台前人流如织，展台大屏幕上循环播放的持续交付平台Wise Build以及容器PaaS平台WiseRun的演示视频引起了很多参会客户对睿云智合产品与解决方案的浓厚兴趣。容器与运维技术峰会今天下午，是大数据核心技术与应用实战、容器与运维技术、Spark 技术、区块链技术四大技术峰会。深圳睿云智合科技有限公司CTO徐年刚，将在容器与运维技术峰会上为大家带来以“容器化引领IT新常态”为主题的精彩演讲。演讲中徐年刚将会就容器技术给云计算带来创新的理念，区别与过去的虚拟化技术，Application Centirc 的容器技术带来一些列理念，标准和规范。结合过去在金融保险行业容器技术推广和落地案例, 详细分析容器技术在企业传统应用自动化部署平台，CI/CD，混合云以及PaaS平台的应用思路，方法和具体实践。演讲时间： 5月19日 14:20 ~ 15:10 睿云智合CTO简介 2002年通过香港专才计划，加盟中信国际电讯集团,先后任职集团首席系统架构师和国际业务系统技术总监, 集团MIS高级部门总监。后期负责集团云计算规划和建设，以及利用云计算进行业务创新。 2011 年加入美国Eucalyptus。先后任职美国研发团队架构师和中国区技术总监，参与国内外多个云平台项目的交付和管理。 2015年，加入中电科华云，任职云计算产品总监。推动电科华云加入了openstack 基金会。 2016年以联合创始人身份加入睿云智合科技有限公司，任职公司技术总监。全面负责睿云的技术路线规划、产品设计与研发管理。我们在 CCTC 2017 B006展台等您！ ...

听睿云智合CTO徐年刚畅谈金融行业基于容器技术的DevOps

2018年1月27日

9月6日，由深圳金融信息服务协会主办，我公司（深圳睿云智合科技有限公司）与Rancher Labs联合协办的，深圳金融IT界容器技术专题研讨会隆重召开并胜利闭幕！会议汇聚了国内外知名的云计算技术大咖，以及招商银行、平安科技、富德生命人寿、广发证券等国内金融科技引领企业的容器技术实践团队的经验分享，为150多人的在场嘉宾奉上了一场堪称金融行业与最前沿容器技术的巅峰碰撞！除了深圳本地的金融行业技术人员，更有来自北京、上海、东北的多家金融机构信息技术团队积极参与，大家纷纷表示会议干货多多，收获颇丰。以下就是小编为大家整理的嘉宾分享内容系列速递，按照演讲顺序，今天为大家推出的是来自前Eucalyptus 架构师&中国区技术总监，现睿云智合CTO，国内云计算资深专家徐年刚（Nathan）的分享：《金融行业基于容器技术的DevOps》究竟DevOps是什么？DevOps是如何促进开发、测试、运维一体化？在企业有哪些实践？以及DevOps和容器技术有什么关系？CI/CD有哪些常见的解决方案？相信Nathan接下来的分享都会给大家一些重要的启发。 DevOps 介绍和实践首先，Nathan简单的介绍了软件产品交付变革。在之前的软件交付中，软件的设计规划，占用的时间都比较长，导致交付到客户手中的时间就较长。随着互联网的飞速发展，现在的交付理念是：小步快跑的方式交付产品，收集用户反馈，持续对产品进行改进。之前我们更多是在讲敏捷开发、而现在更多是DevOps开发运维协作一体化，在企业中已经得到了许多实践应用。一什么是DevOps? A DevOps是英文Development和Operations的组合 B DevOps是一组过程、方法与系统的统称：用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合，这才是DevOps的宗旨。二 DevOps企业实践 DevOps在企业中的实践主要从四个方面来实施：持续部署(CI/CD) 度量和反馈(持续运营) 组织协作(建立全功能团队) 架构解耦(系统解耦，技术解耦) 由于此次研讨嘉宾实在大咖，而时间却有限，所以Nathan这一次先给我们介绍CI/CD。怎么开始CI/CD实践呢？主要是从以下5个方面。持续集成/部署流水线这个环节是怎么样实现的呢？开发者提交代码触发代码更新，然后自动CI构建，在等待构建成功之后，开始部署和执行自动化功能测试。自动化部署成功之后，触发手动部署UAT或者生产环境上以及非功能性测试。说这么多，流水线内部是怎么样的呢?如下图：图1：基本CI构建图2：自动化功能、契约测试图3：部署手动测试那怎样CI/CD流水线设计才算是好的呢？可视化：流水线的运行和停止，成功与失败对所有人直观可见；通过大显示器投放给整个团队反馈：流水线通过显示器，短信，邮件等多种手段及时将失败信息传达到相关团队成员可控制：从构建到生产发布总有一些环节是需要人手动验证的，比如UAT，发布前的批准等；端到端的流水线需要某些环节可以暂停，等待手动继续门禁：流水线中任何一个环节失败应该让流水线停下来，并通知团队，比如自动化测试不通过，Schema升级失败等关注度：当流水线发生失败时团队必须立刻有人关注并解决它，否则流水线的反馈对团队的作用就会大打折扣。Time in “Red”是对流水线关注度的一个重要度量指标内建质量内建质量即在软件产生的各个环节中建立固化的、自动化的质量保障体系。我们来看下一个比较经典的质量控制体系案例：静态程序分析利用代码分析工具，不执行代码的情况下对其质量进行检查，包括重复代码，安全漏洞，及各种代码坏味道；单元测试直接调用应用代码，对程序的输入与输出，以及执行过程是否符合预期进行测试；单元测试不能仅强调覆盖率，而要进行评审，保证有效性和场景覆盖的完整性；自动化契约测试系统提供的每一个接口（Web服务，MQ或其他）都是与其消费者所达成的契约，都必须要有对应的自动化测试；自动化部署验证在生产环境部署完成后，通过自动化方法对其部署是否成功，应用和服务的运行状态进行验证，以判断该部署的新版本是否能够向用户开放；自动化界面测试通过模拟真实人在界面上与系统的交互，对系统的完整业务流程进行验证；这种测试方法更贴近真实，但执行效率也较低；自动化非功能测试非功能测试包括性能测试，压力测试，安全性测试等，也应当集成到端到端的部署流水线中；不过并非每一个故事或特性都需要非功能测试基础设施即代码基础设施即代码，怎么做呢？脚本化一切可以脚本化的、用版本控制库管理所有脚本和代码、禁止人工操作。构建利用Shell脚本文件(.sh)或自动构建工具来进行应用和服务的依赖管理，编译，执行测试，和生成安装包、部署包。不同的语言有不同的构建工具，如Java的Maven，Gradle；C/C++/Objective C的gcc, CMake, Ruby的Rake等。 ...

听广发证券首席架构师-梁启鸿畅谈容器化与组织结构

2018年1月27日

9月6日，由深圳金融信息服务协会主办，我公司（深圳睿云智合科技有限公司）与Rancher Labs联合协办的，深圳金融IT界容器技术专题研讨会隆重召开并胜利闭幕！会议汇聚了国内外知名的云计算技术大咖，以及招商银行、平安科技、富德生命人寿、广发证券等国内金融科技引领企业的容器技术实践团队的经验分享，为150多人的在场嘉宾奉上了一场堪称金融行业与最前沿容器技术的巅峰碰撞！除了深圳本地的金融行业技术人员，更有来自北京、上海、东北的多家金融机构信息技术团队积极参与，大家纷纷表示会议干货多多，收获颇丰。以下就是小编为大家整理的嘉宾分享内容系列速递，按照演讲顺序，今天继续为大家推出的是来自广发证券首席架构师兼信息技术部副总经理 - 梁启鸿的分享：《容器化与组织结构》首先，梁启鸿先生以新常态与去库存展开分享，并且结合金融IT以及现在互联网发展态势，进行了探讨：对于现在传统企业的IT架构而言，代码库存繁多、杂乱、变更快，从而导致运维风险大、成本高，从而无法很好的管理这些代码库存。很多企业就想抓住这样技术变革的机会进行弯道超车，就拿如火如荼的金融行业来说，正在紧锣密鼓的部署着一套套属于自己的架构体系。除此之外，梁启鸿先生还介绍了互联网区块链中的分布式、去中心化、去库存的架构。对于这样的架构我们可能需要用到微服务（微服务架构）。一旦采用微服务，由于生产工具影响生产者关系，容器工具链便成了一个重量级的杀手武器容器！容器化容器化 – 可能是过去五年来软件业最重要的“运动”。容器技术的出现其实是一种潮流，一种趋势，但为什么又要称之为运动呢? 他改变了我们的交付方式，改变了我们的软件思维。等到容器工具出现的时候，DevOps才得到真正的发展。一理性认识容器化技术技术问题解决的关键，没有“银子弹”，容器不是“黑科技” 容器技术，促进了更多新技术发展；容器工具链，促进DevOps；用容器工具链，更便于遵循Micro Service、Reactive、12-Factors 等架构风格、最佳实践；容器对你的代码没有入侵性– 不会让系统更快或者更慢；对你的架构有入侵性– 一旦采用你就要走分布式架构。二容器出现前后的云计算容器出现前大家认为云计算是运维人员使用的技术，接触最多的就是虚拟机。用虚拟机的api与业务应用相结合。这个时期应用架构并没有受到云计算的影响。而容器出现后，云计算技术向应用转移，开发者成为它的直接用户，编排好的容器里的东西运维不需要关注。要用好容器，需要了解好分布式的架构。还用以前的应用架构去搭建是不现实的。组织结构影响组织结构的技术、架构理念与技术运动如下： ▪ 云计算：IaaS/PaaS/SaaS ▪ 微服务：MicroServices、Containerization ▪ DevOps：APM、InfrastructureAsCode、ImmutableInfrastructure、ITAutomation… 一单体架构组织以及微服务架构组织所谓servlet、mvc这些都是一些传统的方式。到2013我们开始用这种全栈同构的基础架构同时走这种微服务方向，你比如像这种电商服务产品中心，购物车，适当性管理形成一些单一的微服务，这些微服务是可以共享这些应用的。二 Gartner的“内架构”与“外架构” 在Inner Architecture中singleresponsibility这种单一微服务，他的边界是很清晰的，技术主要聚焦在业务，有时需要2、3个人的小团队去负责。而outer Architecture，他的可用性、弹性、韧性就只需交给平台去负责管理即可，它有着强大的监控部署体系同时兼容着PaaS平台即服务，这也是容器技术出现之后，PaaS变得更可用、更现实，还解决了一些PaaS中出现的繁琐、碎片化的问题。三从Silo型到Matrix型到DevOps型说到组织结构是从silo型到matrix型到devops型慢慢演变的一个过程。要想建立良好的组织结构，首先需要建立一个平台团队，每一个项目以产品经理去驱动。保障交付的时间，不保障交付的功能。对于传统的流程是从业务的需求，审批，再到硬件的采购，软件的开发，再测试部署，最后客户反馈，每一个环节可能是一个礼拜或者一个月，而现有的agile devops则是直接从业务到软件开发部署，最后反馈，节省了很多时间。四原则建议 ▪ 大系统小做（别想“一口吃个胖子”） ▪ 小团队可以做大事情（从电商到交易终端到交易系统，都是几个人开始） ▪ 全栈（Fullstack）型技术团队让架构更加灵活 ▪ Conway ‘sLaw（康威定律），不要和它“抗争”，遵循它 ▪ Brooks’ Law-技术系统设计的理念，不应该建立在“加人就能增加团队生产力”这种假设上 ▪ 利用工具反过来促进持续试验与学习的文化五围绕OODA闭环的持续交付组织 boyd Loop是美国空军在实战中观察总结的决策闭环。后来netflix利用亚马逊云的ami实现10分钟级别的更新部署。代码越多，bug越复杂，生产环境就越不稳定，形成反脆弱组织的一个期望，我们需要怎么去做呢？就是同一个组织，同一个梦想，同一个kpi，让开发与运维，同一套工具。总结在分享结束之际，梁启鸿先生还总结了：所有金融系统都是一系列组装系统，复杂系统是分开人和机器两个部分的，那么把IT作为一个孵化器，启动一个快速迭代，快速创新同时能够支持像OODA闭环这样的环境，将其应用实践于业务生产中才是我们真正需要做的！...

听平安科技资深专家 – 陈春润畅谈平安金融云之CaaS服务建设和应用

2018年1月26日

9月6日，由深圳金融信息服务协会主办，我公司（深圳睿云智合科技有限公司）与Rancher Labs联合协办的，深圳金融IT界容器技术专题研讨会隆重召开并胜利闭幕！会议汇聚了国内外知名的云计算技术大咖，以及招商银行、平安科技、富德生命人寿、广发证券等国内金融科技引领企业的容器技术实践团队的经验分享，为150多人的在场嘉宾奉上了一场堪称金融行业与最前沿容器技术的巅峰碰撞！除了深圳本地的金融行业技术人员，更有来自北京、上海、东北的多家金融机构信息技术团队积极参与，大家纷纷表示会议干货多多，收获颇丰。以下就是小编为大家整理的嘉宾分享内容系列速递，按照演讲顺序，今天为大家推出的是来自平安科技资深专家 - 陈春润的分享：《平安金融云之CaaS服务建设和应用》分享开始，陈春润先生首先从平安云5大特性展开介绍。和现在的公有云服务供应商对比，平安云在系统、合规以及数据方面有着自己的特点。结合平安集团的发展战略，将平安云平台定义成具备“专业、增值、可靠、安全与合规”特征的金融云服务供应商。专业：理解行业特性，利用平安科技多年的金融IT咨询及研发能力，专业服务于金融行业客户。增值：为金融行业客户提供软件、数据、网络、征信等一系列增值服务，构建起金融同业共赢共生的“超级购物中心”。可靠：利用创新的高可用架构和自动化运维平台为用户提供可靠的基础设施服务打造可信赖的云计算平台。安全：打造适合金融行业的安全体系、符合CSA规范的有强防护能力的云计算平台。合规：重点研究与监管(一行三会)要求的契合度，成为金融云的标杆，为金融行业客提供合规、便利的一揽子云计算服务。除此之外，陈春润先生还表明，平安集团子公司中包含金融行业的各个类别，不同企业、不同来源、不同开发模式的业务系统对底层资源的需求差异很大。所有这些需求对于平安云来说都是必须要满足的。因此平安云会为用户提供不同类型的弹性计算服务，包括：物理机：高性能，高规格虚拟机：灵活、安全的共享容器：灵活、轻量、快速交付这些不同的计算模式可以共享相同的VPC网络，用户可以根据应用架构选择将一部分应用部署在物理机上，也可以部署在虚拟机上或容器服务中。容器服务的设计目标对于容器服务的设计目标，陈春润先生阐述了2点。一、对于大多数租户而言，希望能够使用容器服务加快环境部署的速度，提高扩容的效率，降低运维成本。因此，平安云提供一套简单有效的容器服务产品，使得用户能够自助完成容器部署工作。自助式容器服务（私有或公有云服务） - 用户可定制容器基础架构 - 公共镜像商城 - 私有镜像管理 - 支持混合部署方式 - 兼容平安云基础架构 - 兼容平安应用架构规范二、对于开发团队而言，希望拥有一套从开发测试到生产部署的流水线，容器服务作为流水线中的实际运行环境，完成最后一公里的工作。全流程部署自动化（私有云服务） - 提供API与开发管理平台紧密结合 - 支持开发-测试-生产环境部署流水线 - 用户可定制容器基础架构 - 支持“全容器”和“开发测试容器+生产非容器”型部署需求 - 私有镜像版本管理 - 平台层服务支持平安云容器服务架构容器它有自己运行的方式，不改变任何开发的流程，但是从最终目的来讲，开发不改变传统的架构，容器的功能是很难的发挥的。平安云统一管理区我们会有一个统一的综合管理区，这个区会部署我们一个自己caas服务主体和面对对客户管理的vpi的部分。 - 容器服务门户。 - 门户系统，提供容器服务操作。 - 基于lvs+keepalived部署架构，外接mysql集群。平安云公共服务区我们有自己的每个数据中心，整个平台作为数据中心，每个数据中心内部会有一个资源管理区，这里面会有一些公共的rancher组件，同时支持对每个用户有单独 rancher server，这是我们一个比较大的改动，尽量减少管理域，锁定在一个工作内，这样我们的风险，控制就会更细。 Rancher 服务 - 核心服务组件，主要用于容器调度与部署。 - 基于lvs+keepalived部署架构，外接Mysql集群。 Docker节点 - 用于镜像制作、上传、下载，文件传输，执行Docker命令。 Public Registry - 平安官方公共镜像仓库，同时是官方公共租户的镜像库。 - 采取多节点挂载共享盘部署。租户VPC(某个租户私有的VPC) - 每个租户拥有完整容器部署和运行环境，包括Rancher Server、Docker节点、Private Registry。 - 隔离与其他租户之间的影响，减少跨租户的网络访问。 CaaS核心功能容器这个概念虽然简单，但是对于很多开发人员来讲，对于他们的要求还是很高的，所以我们把它简化，形成一个比较容易理解应用管理，服务管理，镜像管理三大功能，其他高级功能都藏起来，只有资深的管理人员才看的到管理。其它的只是做一些底下的接口之类的。【租户+环境+权限】 - 以租户+环境+角色方式进行权限控制。 - 租户：一个租户包含多个环境，由租户管理员维护。 - 环境：同一类级别的服务集合，由环境管理员管理，包含多个应用管理员。【应用编排】 - 提供官方编排模板。 - 支持Compose部署，扩展了docker compose。【服务管理】 - 丰富的服务创建配置：支持服务link、端口配置、环境变量配置、目录挂载以及资源限制等配置。 - 详细的服务管理：服务信息、服务事件、服务配置。【镜像仓库】 - 所有租户共享镜像商城，每个租户拥有自己的公共仓库，租户内用户共享租户内镜像。 -...

金融IT行业与容器的巅峰对话：听梁胜博士畅谈容器技术未来

2018年1月26日

9月6日，由深圳金融信息服务协会主办，我公司（深圳睿云智合科技有限公司）与Rancher Labs联合协办的，深圳金融IT界容器技术专题研讨会隆重召开并胜利闭幕！会议汇聚了国内外知名的云计算技术大咖，以及招商银行、平安科技、富德生命人寿、广发证券等国内金融科技引领企业的容器技术实践团队的经验分享，为150多人的在场嘉宾奉上了一场堪称金融行业与最前沿容器技术的巅峰碰撞！除了深圳本地的金融行业技术人员，更有来自北京、上海、东北的多家金融机构信息技术团队积极参与，大家纷纷表示会议干货多多，收获颇丰。以下就是小编为大家整理的嘉宾分享内容系列速递，按照演讲顺序，今天先为大家推出的是来自Rancher Labs创始人、CEO梁胜博士的分享：《容器技术发展前景探讨》梁胜博士首先抛出了一个问题点，虽然现在容器技术栈已经非常丰富了。从最底层的云基础设施和操作系统到最上层的管理平台。但是对很多金融企业来说，还是比较难消化的。于是，根据这个情况总结出，在金融企业间的部署和落地主要分2个场景: 应用容器化企业容器服务应用容器化主要是将少量容器化应用投产，利用公有云或私有云资源，与CI/CD整合。企业容器服务则是为整个企业搭建容器化应用部署平台，提高应用开发敏捷性。虽然，容器技术正在飞速发展，然而，容器技术下一步的发展会在哪里呢？虽然老一代的基础设施对应用开发还是有一定的束缚性和局限性。但是博士还是强调了基础设施层的重要性。所以，本次分享博士主要从以下5方面介绍讲解与探析。计算 ARM 依照如今的发展趋势，计算的范围比以前的大得多了。脱离传统的数据中心之后，ARM现在是一个不错的平台。ARM给大家的传统印象是：小、省电。但是现在ARM最新发展，已经从绝对性能上接近intel。虽然现在ARM服务器还未普及,rancher与合作伙伴docker,已经先于一步在ARM上投试了。值得一提的是，现在ARM应用在手机上是在pc端上的几倍。网络和存储网络前几年因为SDN发展得很快，就形成了一个误解: 大规模网络要用SDN和overlay networking搭建。然后事实是: 许多用户更喜欢扁平式网络的简单，高速，易管理。因为SDN现在带来2个问题：加入overlay之后，网管人员不能理解下面的网络拓扑且原来的网管系统不能运行。 SDN在延时和性能方面有很多差距。能够真正的把金融应用做到低延时的物理网络里面去，虽然有退步，但是加上容器技术。带来了许多的灵活性。所以，网络层发生了根本的变化，却不影响应用层。存储存储在基础设施里面是必不可少的一部分。最早的存储就是毫秒级存取的硬盘。最近几年发展迅速的SSD的出现颠覆了存储产业。最令人期待的还是新出现的固态存储技术，比闪存快几个数量级。现在的存储有2个特征：容量大，速度快，而带来的问题就是传统存储软件和处理就不适用了。【主存的技术未来】【传统分布式存储架构】 ceph是非常出名的一款开源容器技术，国内很多开发存储产商都是基于ceph。但是即使是这么受欢迎的技术，在现在的大变革下，也出现问题。 100,000 个卷 -> 每个卷100 IOPs, 100MB/s -> 总共10M IOPs, 10TB/s 【Fusion-ioHA 架构】 Fusion-io成立于2006年，其创始人当时就认识到旋转磁盘时代的存储已经不能满足现代数据的需求。除了应用加速以外，Fusion的存储内存平台还可以降低企业的能耗和总拥有成本。用一个控制器管100,000个卷 -> 给100,000个卷每个单独配备控制器【简单的Controller/Replica架构】容器操作系统现在容器操作系统已经发展成风云群集的时代了，在容器的大舞台上光彩各异。在众多容器操作系统之中，最小的就是rancher os，因此它的优势就在于：效率高，安全性好。容器引擎说到引擎，最著名的就是docker，我们可以看见docker的飞速发展。docker镜像表格式已经成为一种标准了。 docker引擎分支的零散实现，我们可以看见，Rancher是更新到1.12版本（最新）：容器引擎的解剖：调度和编排现在调度和编排系统已经发展成三国鼎立的时代：Swarm、Kubernetes、Mesos。不同的容器编排系统使用因人而异。对于许多人都在预测，最终三者谁会是赢家，其实这种问题就像js框架的使用一样，以下是近几年的js框架的使用情况。而现在Rancher，所做的就是完整的集装箱管理。最后，博士总结了：容器正赶上更新换代的好时机，容器会改变整个基础设施技术栈，而且，会更快的涌现新的容器技术，所以，你准备好搭上这列车了么？...

在Rancher 1.2中实现基于CNI的扁平网络

Rancher容器网络-floating ip解决方案

容器内应用日志收集方案

关于持续交付你准备好了吗？

近期文章

关注我们

Author: admin

近期文章

关注我们