云原生架构重要组成部分之微服务

前言

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

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

前言

什么是云原生？

云原生组成部分

什么是微服务

云原生为什么用微服务架构

什么是云原生？

云原生现在这么火，那究竟什么是云原生呢？

云原生是一种构建和运行应用程序的方法，依赖容器作为技术来实现，是一种新型技术体系。云原生英语（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这样的容器技术来避免污染主机环境并避免过度设计服务。但是，这些方法需要付出努力和时间。

云原生为什么用微服务架构

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