云原生架构与微服务体系

前言：大数据、人工智能、移动互联、云计算、物联网等新一代信息技术的发展为企业数字化转型提供了技术支撑。数字化转型并不是对企业以往的信息化推倒重来，而是需要整合优化以往的企业信息化系统，在整合优化的基础上，提升管理和运营水平，运用新的技术手段提升企业新的技术能力，以支撑企业适应数字化转型变化带来的新要求。因此，本公众号将相继推出企业数字化转型的关键技术与问题一系列推文，以期为目标企业数字化转型提供借鉴性思路。

“企业数字化转型的关键技术与问题”系列推文四：

云原生架构与微服务体系

随着云计算平台的成熟和分布式框架的普及，应用上云已经是不可逆转的趋势，未来应用会分成两种，一种是“构建云”的，另一种是“基于云构建”的应用。

真正的云化不仅仅是基础设施和平台的变化，应用也需要做出改变，摈弃传统的土方法，在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点重新设计，从而建设全新的云化的应用，即云原生应用。

在云环境下怎样保证在应用程序越来越大、功能越来越复杂的情况下，还能够做到敏捷开发并保证可用性呢？云原生有一套完整的体系和方法论。

什么是云原生？

云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。云原生（CloudNative）是一个组合词，Cloud+Native。

Cloud表示应用程序位于云中，而不是传统的数据中心；

Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。

不同的人和组织对云原生有不同的定义，相同的人和组织在不同时间点对云原生也有不同的定义：

•2013年，Pivotal公司的Matt Stine首次提出云原生（CloudNative）的概念；

•2015年，Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12因素、微服务、自敏捷架构、基于API协作、扛脆弱性；

•2017年，Pivotal最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器；

•2018年，CNCF又更新了云原生的定义，把服务网格（Service Mesh）和声明式API给加了进来；

可以简单的理解为：

云原生 = DevOps+持续交付(Continuous Delivery)+微服务(Micro Services)+敏捷基础设施(Agile Infrastructure)+12要素(The Twelve-Factor App)+服务网格（Service Mesh）+声明式API。

云原生不但包括根据业务能力对公司进行文化、组织架构的重组与建设，也包括方法论与原则，还有具体的操作工具。采用基于云原生的技术和管理方法，可以更好地把业务生于“云”或迁移到云平台，从而享受“云”的高效和持续的服务能力。

原生与传统应用有比较明显的区别，云原生更倡导敏捷、自动化、容错，而传统应用则大多还处于原生的瀑布开发模型和人工运维阶段。

什么是微服务？

随着业务越来越复杂，业务架构也经历了不断变化和演进，每一次演进都是为了解决上一代系统架构的痛点。

第一代单体架构把所有业务依赖的组件、库全部打包到一个执行程序，业务相互调用，大大增加了系统复杂度，导致系统维护成本高，改动影响大，发布风险高；并且系统完全封闭，内部组件不能共享给其他组件调用，导致产品能力不能共享，大大降低开发效率。

第二代面向服务架构SOA（Service Oriented Architecture）是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在与操作系统进程中，各个服务之间通过网络调用。

第三代微服务架构是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

微服务是一种去中心化的架构，一般和更细粒度的容器配合使用，天生自带很强的共生性。从早期的集中式架构，到分布式架构，再到现在更细粒度化的微服务，其实一直朝着去中心化的趋势发展，具备更强的灵活性以及更适合云的特点。微服务是未来一种非常主要的、应用广泛的架构，但并不一定说它会统治一切。微服务化更适合无状态、高迭代的业务场景。

微服务的粒度与团队组织方式是相关，与业务功能的构成相关，与数据相关。在业务功能方面，尽量做到一个模块中的业务高度类聚集，和外部模块做到松耦合，获取灵活性；在数据方面，一个微服务尽量不要和外部频繁的交互数据，大量的API交互对性能和可靠性都有影响。

三、微服务在实践过程中最大的难点是什么？

微服务在实践过程中，最大的问题是团队之间的运作和管理。康威定律提到，有什么样的团队组织方式，就有什么样的业务架构。业务架构，是和团队组织架构相匹配的，当我们把一个大的系统，拆分成小的服务时，团队会随之变化。团队成员需要适应微服务的开发模式，微服务对每个程序员有着更高的要求。

微服务实践的难点不在于没法拆分，难点在于很多人的思想停留在以前的架构思想下。建议逐步改造、持续迭代地改造架构。新业务、新团队可以独立地采用微服务化运作。

四、微服务、容器技术两者的关系？两者结合带来什么新趋势？

微服务是一种架构思想，而容器，或者说以Docker为代表的容器技术，是一种运行载体。容器天生适合细粒度的微服务，容器管理和分发需要Docker的支持。两者结合，就是去中心化思想的实践。

伴随互联网与云计算的发展，什么样的架构或者产品研发模式是适合云模式的？是传统的集中式架构吗？分布式架构吗？现在创业型公司的特点：完全基于云端，轻资产，小团队作战，快速的产品迭代。为了适应这些特点，必须基于云的原生特点去设计应用架构，所以微服务和容器发展的新趋势，就是去实践Cloud Native。

在云时代，全部应用都基于云去构建，并不适合套用传统的研发模式。Cloud Native是指云原生的应用架构，是专门针对云的架构。它主要包括三个部分，一种全新的架构思想（微服务），一种业务运行管理模式，以及一种团队组织管理方式。关乎DevOps、小团队、敏捷开发。Cloud Native既不是一个新的技术，也不是一套新的架构，而是产品研发、运营的全新模式。它是在云的生态场景生长出来的，和云的关系是一种鱼和水的关系。

五、怎么处理微服务与外部相连，以及获取数据？

微服务是通过API对外提供服务，本身是一个独立的自治系统，所以不存在需要与很多数据中心相互连接的情况；如果需要通讯，直接适用公网连接就可以。

换句话说，微服务和微服务之间的数据通讯是通过API调用的。没有所谓的内部的进程间、共享信号、共享内存队列的模式。一个微服务对外提供的服务一定是封装好的、接口式的。

总结

云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论，它还包括研发流程规范，软件架构，基础设施和工具集，为我们在基于的云上开发提供了指导思想和最佳实践。

只有按照云原生的技术和管理方法，才能更好地把业务生于“云”或迁移到云平台，从而享受“云”的高效和持续的服务能力。

为了让我们的产品更加符合云原生，我们应该紧跟开源社区，顺势而为，迎合云原生的理念，迎合社区的发展方向。

经邦大数据作为云原生时代下，大数据智能微服务平台的倡导者和积极实践者，是国内领先专注于人的行为管理、分析和预测的软件开发商和数据平台运营服务商。通过兼收并蓄国际最前沿的软件技术和大数据解决方案，结合国内市场情况，自主创新研发在中国具有前瞻性和实用性的企业级一站式管理解决方案，为中国用户构建具有先进管理理念, 灵活适用, 经济高效的敏捷解决方案，帮助各行业 用户从容应对瞬息万变的市场,实现数字化原生管理。

经邦智能分析微服务平台致力于传统企业的数字化转型，以及各类微服务应用开发。传统企业的数字化转型，不仅是选择产品，选择技术，改变开发理念就能够完成的简单过程，还涉及到用户自身的内部组织架构，乃至整个思想、思路的变革，是一个从内到外进行整体的变革过程。

经邦智能利用云原生技术，构建统一的云化操作系统，帮助我们的客户进行云化/数字化/互联网化的转型需求，实现开发运维的一体化/微服务/敏捷开发的需求，也可以实现混合云的部署需求，来满足以应用为中心的开发运维体系。