云原生架构重要组成部分之微效劳

前言

近几年来，云计算与微效劳架构非常火，运用广泛。各大厂商公司都运用了该技术架构，随着技术与理念的晋级迭代，云原生概念应世而起，如今火的一塌糊涂。做为新时代的程序员，我们要抓住云原生的浪潮。

这篇文章呢大致分为四部分，第一部分简单谈一下什么是云原生，让小伙伴们有个大致理解。第二部分谈一下云原生的组成部分。第三部分呢我们谈一谈云原生的重要组成部分之一 ——微效劳，什么是微效劳？第四部分主要谈谈云原生为什么用微效劳架构。
目录
前言
什么是云原生？
云原生组成部分
什么是微效劳
云原生为什么用微效劳架构
什么是云原生？

云原生如今这么火，那终究什么是云原生呢？
云原生是一种构建和运行应用程序的方法，依赖容器作为技术来实现，是一种新型技术体系。云原生英语（CloudNative）Cloud表示云。Native表示应用程序从设计之初即考虑到云的环境，充沛利用和发挥云平台的弹性+分布式优势。云原生顾名思义，就是基于云计算特性所设计的应用效劳，得益于云计算快速开展，基于云计算特性所设计的云原生应用相比传统的单体应用在安全性，扩展性，快速迭代，运维等各方便都有宏大的领先优势。
云原生并不是指某一种技术，它是一种架构设计理念，只要符合这种架构设计理念的应用，都可以称为 云原生应用。
以下是云原生概念呈现的几个时间点。

2013年Pivotal公司的Matt Stine首次提出云原生（CloudNative）的概念；2015年Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12因素、微效劳、自敏捷架构、基于API协作、扛脆弱性；2017年Matt Stine将云原生架构归纳为模块化、可观察、可部署、可测试、可交换、可处置6特质；到如今Pivotal最新官网对云原生概括为4个要点：DevOps，持续交付，微效劳，容器。

云原生组成部分

根据第一部分，到如今Pivotal最新官网对云原生概括为4个要点：DevOps，持续交付，微效劳，容器。

1.DevOps

维基百科定义
DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变卦”的流程，来使得构建、测试、发布软件可以更加地快捷、频繁和可靠。
DevOps，Dev+Ops，开发和运维。这是一个敏捷思维，为云原生提供持续交付才干。

2.持续交付

摒弃传统的瀑布式开发模型，采用分布式架构+敏捷开发+微效劳架构+DEVOPS形式。开发做到准时开发，快速开发，快速更新。要求开发版本和稳定版本并存。

3.微效劳

第三部分会详细介绍什么是微效劳，这里简单说明一下。
微效劳是将单一程序划分为一个一个独立的模块，自成一个效劳，各个独立模块可以根据业务需求等使用不同的技术实现，它们之间通过轻量级的通信机制停止调用。（通常是基于HTTP的RESTful API）。

4. 容器

云原生更偏重应用程序的运行环境， 它是以K8S和容器为根底的云环境。目前Docker是应用最为广泛的容器引擎，容器化为云原生微效劳提供施行保证，K8S用于容器管理，容器间的负载平衡。

什么是微效劳

微效劳是当下非常火的架构技术，无论你是否接触云原生，这一块你都是要理解的，因为目前国内绝大多数公司在技术选型上是采用的微效劳架构，由此可见学习微效劳是多么的重要。如今云原生架构火的一塌糊涂，微效劳又是其重要组成部分，你懂得。

什么是微效劳，我们先来看一下维基百科的定义：
一种软件开发技术- 面向效劳的体系构造（SOA）架构款式的一种变体，它提倡将单一应用程序划分成一组小的效劳，效劳之间互相协调、互相配合，为用户提供最终价值。每个效劳运行在其独立的进程中，效劳与效劳间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个效劳都围绕着详细业务停止构建，并且可以独立地部署到消费环境、类消费环境等。另外，应尽量防止统一的、集中式的效劳管理机制，对详细的一个效劳而言，应根据上下文，选择适宜的语言、工具对其停止构建。
微效劳（或微效劳架构）是一种云原生架构方法，其中单个应用程序由许多松懈耦合且可独立部署的较小组件或效劳组成。
微效劳顾名思义，就是微小的效劳。把之前单一架构的项目划分为一个一个的小项目，划分成的每一个小项目都可以是独立的效劳，可以独立运行独立部署。假设一个微效劳要调用另一个微效劳，那我们可以用RESTful API停止调用。这样一来，每个项目之间的耦合度大大降低，减少了后期维护的本钱。
在这里小梦推荐的微效劳技术栈是Spring Cloud，Spring Cloud是目前微效劳开发的主流技术栈，大多数公司都在使用，小伙伴们回头可以学习学习。
Spring Cloud核心组件

效劳网关 Zuul效劳注册发现 Eureka+Ribbon效劳配置中心 Apollo认证受权中心 Spring Security OAuth2效劳框架 Spring MVC/Boot

当然没有一种技术是完美的，都会有缺点和缺乏。有个问题大家可以一起考虑一下“微效劳会不会呈现过多的微效劳无法管理的问题？ ” 。
在小梦看来，会呈现过多的微效劳无法管理的问题。当把一个单体效劳划分为细小的微效劳的时候，每个微效劳之间是互相独立的，它们可以有着不同实现方式，不同的缓存，数据库，效劳器。当效劳数量和范围在一定可控的范围内，那我们管理起来相对容易，每个团队负责一块效劳，记录自己负责的效劳的技术栈，以及数据库和部署的效劳器的安康状态。试想当划分的效劳数量变的非常庞大，每个效劳都要独立部署，当资源有限的时候，这就变得非常复杂。相当于一个人原本一天能做一个工作，但你给他布置了10个工作，打~他也做不完啊。微效劳也一样，当数量大起来，也就复杂起来。
当然我们可以通过Docker这样的容器技术来防止污染主机环境并防止过度设计效劳。但是，这些方法需要付出努力和时间。
云原生为什么用微效劳架构

云原生为什么用微效劳架构可想而知，微效劳架构非常适宜云原生应用程序，我们将应用程序设计为预期将部署在分布式、可扩展的根底架构上。微效劳使效劳模块化，不在单一。每个微效劳将分配多个效劳器节点，允许部署冗余微效劳架构。假设主模块或效劳因任何原因而失败，冗余效劳模块会替代主模块停止效劳，好比一个公司的股票系统正常运行中，突然一个系统效劳宕机了，另一个效劳接受到信号接替它继续工作，等维护开发人员处置宕机问题，再交由主效劳模块停止效劳，这样用户再操作股票时不会有影响。假设我们使用的不是微效劳架构而是单一架构，一旦效劳宕机，那系统就瘫痪了，公司将面临的宏大损失。

这篇文章假设对小伙伴们有协助的话，希望点个赞支持一下~ 非常感激~