CloudNative综述

微服务是为了实现云服务的一部分，微服务-服务管理是基于Cloud native而来，那么Cloud native讲究的是，DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等。

通俗来讲，因为云服务通常是由组织架构决定技术架构，想要搭建云服务的平台，需从组织架构层面进行组织内部与组织直接的合理划分（康威定律），高速迭代导致传统开发-测试-运维一步步走成了历史，开发即测试即运维，开发的边界更加的模糊（DevOps）。通过此种架构达确保让代码能够快 速、安全的部署到产品环境中，它通过将每一次改动都提交到一个模拟产品环境中，使用严格的自动化测试，确保业务应用和服务能符合预期。因为使用完全的自动 化过程来把每个变更自动的提交到测试环境中，所以当业务开发完成时，你有信心只需要按一次按钮就能将应用安全的部署到产品环境中。（持续交付）通过CI（持续集成）、代码检查、UT（单元测试），持续部署等方式，打通开发、测试、生产的各个环节，持续的增量的交付产品。 由于架构边界更加模糊，所以不同业务可以拆分为不同的服务，独立发布部署（微服务），并将服务进行虚拟化操作，方便部署至不同的物理机。通过对不同物理机的合理划分与监控可以提供弹性、按需的计算、存储、网络资源能力。（敏捷基础设施）。

 

Cloud Native 解决的诉求

• 持续交付、DevOps、微服务解决–>更快的上线速度
• 微服务解决–>细致的故障探测和发现
• 微服务解决–>故障时能自动隔离
• 敏捷基础设施、微服务解决–>故障时能够自动恢复
• 敏捷基础设施、微服务解决–>方便的水平扩容

拥抱微服务

微服务提供的支撑服务

很好的一张图，直接拿来用了。

附上我基于此绘制的流程图

支撑微服务的平台

• Kubernetes –>谷歌的微服务整体解决方案，更偏向于运维人员。
• Mesos+Docker
• OpenShift V3
• Machine + Swarm + Compose
• OpenStack + Docker
• Spring cloud 基于spring，更偏向于开发人员
• Cloud Foundry Lattice 其他技术等等

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）：把日志作为事件流，不管理日志文件，通过一个集中的服务，由执行环境去收集、聚合、索引、分析日志事件。

 

---