怎样关闭系统自动更新 一篇文章带你了解Cloud Native(2)

敏捷基础设施、微服务解决-->故障时能够自动恢复

敏捷基础设施、微服务解决-->方便的水平扩容

推行Cloud Native可以从如下几方面入手：

组织变革：根据康威定律，如果要达到比较理想的云化效果，必须进行组织变革。一个合理的组织架构，将会极大提高云化的推行。相信很多公司，在决定搞云计算后，都大大小小进行了部门合并和组织结构调整。这块水比较深，相信很有变革的切肤之痛。

推行DevOps文化：在公司层面推行DevOps文化，倡导开放、合作的组织文化，打破“部门墙”。

推行持续交付：联合开发、质量、运维各个环节，打通代码提交、代码检查、UT、开发环境部署、staging环境部署、线上环境部署等流水线。

建设敏捷基础设施：这部分是整个Cloud Native的根基。这部分可以采纳的技术非常多，开源的、商用的都比较多。

采用微服务架构：微服务架构是Cloud Native的一个核心要素。微服务包含几方面的内容： （1）有支撑微服务的平台。

（2）有符合微服务平台规范的APP。

（3）如何引入微服务。

（4）微服务核心技术点。

支撑微服务的可选技术框架比较多，每个公司都可以根据自身情况选择合适的技术框架。比如：

Kubernetes

Mesos+Docker

OpenShift V3

Machine + Swarm + Compose

OpenStack + Docker

Cloud Foundry Lattice 其他技术等等

这方面的资料非常多，不再细讲。

APP要符合12因子（Twelve-Factor）的规范：

基准代码（Codebase）：代码必须纳入配置库统一管理。

依赖（Dependencies）：显式的声明对其他服务的依赖，比如通过Maven、Bundler、NPM等。

配置（Config）：对于不同环境（开发/staging/生产等）的参数配置，是通过环境变量的方式进行注入。

后台服务（Backing services）：对于DB、缓存等后台服务，是作为附加资源，可以独立的Bind/Unbind。

编译/发布/运行（Build、Release、Run）：Build、Release、Run这三个阶段要清晰的定义和分开。

无状态进程（Processes）：App的进程是无状态的，任何状态信息都存储到Backing services（DB，缓存等）。

端口绑定（Port binding）：App是自包含的，所有对外服务通过Port Binding暴露，比如通过Http。

并发（Concurrency）：App可以水平的Scaling。

快速启动终止（Disposability）：App进程可以被安全的、快速的关闭和重启。

环境一致性（Dev/prod parity）：尽可能的保持开发、staging、线上环境的一致性。

日志（Logs）：把日志作为事件流，不管理日志文件，通过一个集中的服务，由执行环境去收集、聚合、索引、分析日志事件。

直接对原有系统进行微服务改造，是比较困难的，几乎是不现实的。比较合理的方法是新系统采用微服务开发，对老系统进行服务封装，系统架构如下所示：

Monolith系统：对应企业老的系统。

The Anti-Corruption Layer：反腐层，这层完成对老系统的桥接，并阻止老系统的腐烂蔓延。它包含三部分：

Facade：简化对老系统接口的对接。

Adapter：Request，Response 请求协议适配

Translator：领域模型适配，转换微服务模型和老系统模型。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/sanxing/article-58525-2.html