标签：ons 元数据 导致 工具 展开 app openstack 两种 帮助
云计算的本质是提高效率，而不是降低成本，公有云就是要提高社会的效率，私有云就是要提高 IT 的效率。
从这个角度看，实施云计算就是做精益运营，而微服务架构为精益运营提供了架构上的保证，因为微服务是小的、容易变化的、容易控制的。
大家好，我是焦烈焱，今天主要介绍普元利用云计算模式，帮助企业实施数字化转型过程中，在技术上遇到的挑战，以及我们解决问题的方法。
首先解释一下什么是数字化？数字化就是把人、事/物和商业联系起来，Garnter 提到未来的企业都是数字化的企业，IT将成为企业核心竞争力，甚至每个企业都是一个 IT 企业。类似的概念有金融科技（FinTech）、软件驱动企业、API经济，我觉得还是数字化描述得比较本质，大云物移/SMAC这些提法就技术化了。
企业数字化，我们近些年遇到了很多类似的案例，这里不一一展开，但需要说明的是，这些都是通常意义上的传统企业，他们比以往更有动力做数字化的商业模式。
数字化对 IT 的要求，来自从对内服务为主，增加了对外服务的模式，以云计算的模式，直接面向最终客户和合作伙伴，由于服务对象、业务范围发生了很大变化，需要采用不同的架构实现。
微服务是实现对外服务所必要的，原因有三：1、核心来自对外服务往往与互联网企业竞争，需要更快的速度；2、这些服务往往不是企业当前擅长的，要快速试错；3、业务的压力服务预计，需要架构的弹性。例如我们一个农村商业银行的客户，做了一个农产品买卖的电子商务平台，电子商务业务是他们不擅长的，而直接竞争对手就包括目前的互联网企业，迫使我们必须学习互联网企业的经验。
在数字化过程中，我们实施的案例往往采用混合的架构，新事新办法、老事老办法做过渡，而新事一般采用微服务架构。
上图是一个微服务架构的全景图，注意右上角用 ESB 与传统系统连接。说个题外话，最近很多次交流，大家都提到嵌入式的集成与 ESB 集成模式的关系，应该如何选择，我认为两种都需要，前者对同质系统、自研系统比较合适，而后者用于异构的集成，例如我外购了一个产品，无法把集成的逻辑嵌入到该产品中，只能通过 ESB 进行连通。
我们在实施微服务架构，支撑企业数字化的过程中，遇到了很多挑战，主要来自技术欠债太多、隐形成本过高、知识缺少共享与协作等等。
遇到的问题太多，就事论事的解决问题肯定是不行的，我们在实施过程中从技术的精益运营入手，把技术当作一个Business（这个在此翻译成商业、生意最恰当，而不是业务）来做，从架构、治理、协作等各个方面设立了若干专题，在这些专题中通过技术手段提高效率、降低成本。
其实，云计算的本质是提高效率，而不是降低成本，公有云就是要提高社会的效率，私有云就是要提高 IT 的效率。从这个角度看，实施云计算就是做精益运营，而微服务架构为精益运营提供了架构上的保证，因为微服务是小的、容易变化的、容易控制的。
下面，我主要从架构高可用、提升协作效率和提升治理效率三方面谈一下经验。
介绍一下技术欠债，我们以前基于 OpenSatck + CloudFoundry 做基础架构，当年和银联的同事一起，基于 OpenStack 管理了上千台的物理机。
那时，我们花了很大精力在如何实现高可用，做横向、纵向伸缩，但还是有些不足，例如由于虚拟机启动较慢，导致切换的时候时间窗口太长，为了缩短时间就设置了一些已经启动好的虚机，应用也做成了彻底的无状态，例如 JVM 等使用了共享方式，而不是多份 copy，减少镜像的大小，但总体上资源利用率是有待提高的。
再如高可用的实现中，OpenSatck 实现起来就要引用很多组件，能实现，但是比较复杂。
通过 OpenStack 和 CloudFoundry 的实践，我们发现，他们是为了管理而生的，架构的核心是为了更灵活的管理各种设备，而不是为了高可用，类似的还有虚拟机技术，也是为了更方便管理的目的。
基于这样的思考，我们决定把 OpenStack 做薄，让他做最擅长的虚机管理，而高可用等能力交给 Kubernetes，因为在架构上后者天生为调度而设计。
至于为什么选择 Kubernetes，先前微课堂讲师宋潇男已经做了介绍，大家可以在 EAII 公众号（微信号：eaworld）下载相关PPT。
我们用 DevOps 提高协作的效率，加快开发、测试、部署的效率，首先是将应用代码与基础设施分离，开发工程师提供应用的代码、配置、环境信息、安装介质、实现后的软件资源（例如对外接口、数据库表），通过 DevOps 平台进行自动化的部署。
上图为微服务 DevOps 的概念模型，内容有点多，就不一一解释了。
由于在 DevOps 过程中有很多的工具，协作就是要把这些工具打通，协作起来，例如需求是用 Jira 管理的，在 DevOps 平台注册用户后，就可以在 Jira 里面自动注册。
我们做了很多看板，让需求、设计、运维、测试不同角色的人员，通过看板能够了解其他环节的工作，而看板的数据来自于被集成系统，例如在 Jira 里面编辑需求的时候，会自动推送到 DevOps 的看板上。
集成 DevOps 领域工具链，是基于概念模型，结合 AAAA 完成的，这里面工作量比较大，而且上述工具链的审计我们还没有实现，比较复杂。
同时，我们的 DevOps 平台准备基于Kubernetes 实现微服务新版本发布、金丝雀测试、预发和滚动更新，这也是一个基于 OpenStack 比较复杂的工作，用 Kubernetes 的标签概念就比较简单。目前正在考虑通过数据服务解决服务发布的数据库蓝绿部署问题，帮助微服务做好发布、回滚、灰度发布。
面向互联网应用的微服务架构，是一个分布式架构，比较复杂，因此必须提高治理的效率，我们是用元数据来完成的，这是一个元数据在微服务架构中应用的例子。
有了微服务的元数据，就可以做很多事情，上图是通过元数据做各阶段版本的比较。我们曾经在某特大型城市商业银行，利用元数据从设计工具（PowerDesiner）、预发环境、生产环境采集软件资源信息（例如数据库），预发环境、生产环境进行比对，列出不一致的地方，再参考设计，人工确认无误的情况下，才发起生产上线流程。
还有在云中的自适应安全，都可以基于元数据来实现，普元首席架构师顾伟在 CSDN云计算大会的分享中，也会讲到这一点。
元数据的话题，在微课堂也已讲过两次，包括应用场景和技术实现，大家可以关注 EAII 公众号（微信号：eaworld）。
总结一下今天的内容：我们在这些年的实践中，用微服务架构支撑企业的数字化，采用的技术从 OpenStack + CloudFoundry 等管理为主，逐步过渡到 Kubernetes + OpenStack 的模式，同时利用元数据技术提高微服务架构的治理效率，用 DevOps 提高协作的效率。
在精益运营的方面有很多功课我们要做，包括今天的内容，我们会逐步分专题细化共享出来，谢谢大家！
标签：ons 元数据 导致 工具 展开 app openstack 两种 帮助
原文地址：http://www.cnblogs.com/mjzhang/p/7494234.html
