微服务架构的前世今生

传统行业向互联网行业的转型

背景

2012年以后，因为移动互联网的兴起，随着网名数量的增多，需求变化大，用户群体大。导致已有的应用程序无法抗住大规模的并发，且版本迭代麻烦，扩展不够灵活，应对外界环境能力薄弱，所以微服务思想就应运而生了。

2014年微服务的概念传入中国，2015年左右国内大厂开始进行项目升级，转战微服务。2018年中小型企业也开始进行微服务架构升级。

传统行业的产品是必然要向互联网行业进行转型的，马云爸爸曾经说过：如果说传统制造业不拥抱互联网的话，那注定是死路一条。而转型的过程当中，底层的架构模式也不再是传统的单体架构了，而是全新的微服务架构模式。

马云曾说道：十五年以前，我在全国各地，至少两三年内讲过两三百次这样的演讲，提醒大家互联网、电子商务对各行各业会有冲击，但是没有人把这个话当回事情，那个时候我是Nobody，讲话等于白讲。但是今天，既然我已经有这样的资源，我还是要告诉大家，未来二三十年，这个世界的变化超过所有人的想象力，而且绝大部分人是很倒霉的。今天的传统企业如果依然固步自封，不接受新时代和新的商业模式，势必会被淘汰。

传统行业与互联网行业的区别

互联网发展史

web 1.0

用户只能搜索和阅读网络信息。比如中国的几大门户网站：搜狐、新浪、网易、腾讯，平台提供内容和数据，用户被动接受，和用户缺乏交互。

web 2.0

用户能够创造内容，并分享在网路平台上跟大家进行互动，而不再只是单纯的访问者；这种范式的发展重新定义了市场和商业模式。比如QQ、天涯、微博、淘宝、美团、滴滴，提供一个平台，用户你们自己玩。用户需要注册，用户和平台交互变得很强，用户和用户之间可以交流，数据几乎由用户产生。

web 3.0

网络在接受信息的同时，通过数据分析，能够根据用户的喜好产生出新的数据和信息并推送给用户。比如网易云音乐的推荐，搜索引擎的推荐，淘宝的商品推荐，地图应用的出行规划，堵车预测等等。其特征是使用 web 2.0 时代所产生的大量数据，更加精准、实时和深入的为用户提供服务。一个简单的例子：当你在淘宝上买了某件商品后，订单下方会出现很多类似商品推送。

总结

比如：你家楼下餐馆代表互联网，你饰演互联网用户。

  • WEB1.0时代：你晚上一进餐馆，老板给你上了一桌子菜，说兄弟都是你的吃吧！（不分析）你自己挨个尝试，因为你不知道哪个菜好吃。（缺乏交互）
  • WEB2.0时代：你晚上一进餐馆，你说：老板来斤饺子。老板说：没有饺子有面条。你说来碗面条，老板给你上了一碗面条。（被动分析）或者，你不知道吃什么好，但是坐在你旁边的食客会告诉你哪个好吃。（用户交互）
  • WEB3.0时代：你晚上一进餐馆，一进门老板就说：客官，来碗面条吧！你问为啥，老板说，你连续吃一礼拜面条了。（主动分析）WEB 3.0 是微服务、大数据、云计算、人工智能的时代。

技术架构演变

下图表示从单体应用逐渐转变为微服务应用。

单一应用架构

通俗地讲，“单体应用（monolith application）”就是将应用程序的所有功能都打包成一个独立的单元。当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。

特点

  • 所有的功能集成在一个项目工程中；
  • 所有的功能打一个 war 包部署到服务器；
  • 应用与数据库分开部署；
  • 通过部署应用集群和数据库集群来提高系统的性能。

优点：

  • 「开发简单」：一个 IDE 就可以快速构建单体应用；

  • 「便于共享」：单个归档文件包含所有功能，便于在团队之间以及不同的部署阶段之间共享；

  • 「易于测试」：单体应用一旦部署，所有的服务或特性就都可以使用了，这简化了测试过程，因为没有额外的依赖，每项测试都可以在部署完成后立刻开始；

  • 「容易部署」：整个项目就一个 war 包，Tomcat 安装好之后，应用扔上去就行了。群化部署也很容易，多个 Tomcat + 一个 Nginx 分分钟搞定。

缺点：

  • 「妨碍持续交付」：随着时间的推移，单体应用可能会变得比较大，构建和部署时间也相应地延长，不利于频繁部署，阻碍持续交付。在移动应用开发中，这个问题会显得尤为严重；
  • 「不够灵活」：随着项目的逐渐变大，整个开发流程的时间也会变得很长，即使在仅仅更改了一行代码的情况下，软件开发人员需要花费几十分钟甚至超过一个小时的时间对所有代码进行编译，并接下来花费大量的时间重新部署刚刚生成的产品，以验证自己的更改是否正确。如果多个开发人员共同开发一个应用程序，那么还要等待其他开发人员完成了各自的开发。这降低了团队的灵活性和功能交付频率；
  • 「受技术栈限制」：项目变得越来越大的同时，我们的应用所使用的技术也会变得越来越多。这些技术有些是不兼容的，就比如在一个项目中大范围地混合使用 C++ 和 Java 几乎是不可能的事情。在这种情况下，我们就需要抛弃对某些不兼容技术的使用，而选择一种不是那么适合的技术来实现特定的功能。
  • 「可靠性差」：某个环节出现了死循环，导致内存溢出，会影响整个项目挂掉。
  • **伸缩性差：**系统的扩容只能针对应用进行扩容，不能做到对某个功能进行扩容，扩容后必然带来资源浪费的问题。
  • 「技术债务」：假设我的代码库中有一个混乱的模块结构。此时，我需要添加一个新功能。如果这个模块结构清晰，可能我只需要2天时间就可以添加好这个功能，但是如今这个模块的结构很混乱，所以我需要4天时间。多出来的这两天就是债务利息。随着时间推移、人员变动，技术债务必然也会随之增多。

垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。

特点

  • 以单体结构规模的项目为单位进行垂直划分，就是将一个大项目拆分成一个一个单体结构项目。
  • 项目与项目之间存在数据冗余，耦合性较大，比如上图中三个项目都存在用户信息。
  • 项目之间的接口多为数据同步功能，如：数据库之间的数据库，通过网络接口进行数据库同步。

优点

  • 开发成本低，架构简单；

  • 避免单体应用的无限扩大；

  • 系统拆分实现了流量分担，解决了并发问题；

  • 可以针对不同系统进行扩容、优化；

  • 方便水平扩展，负载均衡，容错率提高；

  • 不同的项目可采用不同的技术；

  • 系统间相互独立。

缺点

  • 系统之间相互调用，如果某个系统的端口或者 IP 地址发生改变，调用系统需要手动变更；
  • 垂直架构中相同逻辑代码需要不断的复制，不能复用。
  • 系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。

SOA 面向服务架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心。当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。

❝

P.S. 从软件设计的角度上来说，ESB 是一个抽象的间接层，提取了服务调用过程中调用与被调用动态交互中的一些共同的东西，减轻了服务调用者的负担。Java 编程思想里提到：“所有的软件设计的问题都可以通过增加一个抽象的间接层而得到解决或者得到简化！”简单来说 ESB 就是一根管道，用来连接各个服务节点。为了集成不同系统，不同协议的服务，ESB 做了消息的转化解释和路由工作，让不同的服务互联互通。

❞

特点

  • 基于 SOA 的架构思想将重复公用的功能抽取为组件，以服务的形式给各系统提供服务。
  • 各项目（系统）与服务之间采用 WebService、RPC 等方式进行通信。
  • 使用 ESB 企业服务总线作为项目与服务之间通信的桥梁。

优点

  • 将重复的功能抽取为服务，提高开发效率，提高系统的可重用性、可维护性。
  • 可以针对不同服务的特点制定集群及优化方案；
  • 采用 ESB 减少系统中的接口耦合。

缺点

  • 系统与服务的界限模糊，不利于开发及维护。
  • 虽然使用了 ESB，但是服务的接口协议不固定，种类繁多，不利于系统维护。
  • 抽取的服务的粒度过大，系统与服务之间耦合性高。
  • 涉及多种中间件，对开发人员技术栈要求高。
  • 服务关系复杂，运维、测试部署困难

微服务架构

特点

  • 将系统服务层完全独立出来，并将服务层抽取为一个一个的微服务。
  • 微服务中每一个服务都对应唯一的业务能力，遵循单一原则。
  • 微服务之间采用 RESTful 等轻量协议传输。

优点

  • 团队独立：每个服务都是一个独立的开发团队，这个小团队可以是 2 到 5 人的开发人员组成；
  • 技术独立：采用去中心化思想，服务之间采用 RESTful 等轻量协议通信，使用什么技术什么语言开发，别人无需干涉；
  • 前后端分离：采用前后端分离开发，提供统一 Rest 接口，后端不用再为 PC、移动端开发不同接口；
  • 数据库分离：每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库；
  • 服务拆分粒度更细，有利于资源重复利用，提高开发效率；
  • 一个团队的新成员能够更快投入生产；
  • 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值；
  • 可以更加精准的制定每个服务的优化方案（比如扩展），提高系统可维护性；
  • 适用于互联网时代，产品迭代周期更短。

缺点

  • 微服务过多，服务治理成本高，不利于系统维护；
  • 分布式系统开发的技术成本高（网络问题、容错问题、调用关系、分布式事务等），对团队挑战大；
  • 微服务将原来的函数式调用改为服务调用，不管是用 rpc，还是 http rest 方式，都会增大系统整体延迟。这个是再所难免的，这个就需要我们将原来的串行编程改为并发编程甚至异步编程，增加了技术门槛；
  • 多服务运维难度，随着服务的增加，运维的压力也在增大；
  • 测试的难度提升。服务和服务之间通过接口来交互，当接口有改变的时候，对所有的调用方都是有影响的，这时自动化测试就显得非常重要了，如果要靠人工一个个接口去测试，那工作量就太大了，所以 API 文档的管理尤为重要。

总结

分享两个小故事，帮助大家更好的理解 SOA 与微服务的区别。

故事一：

❝

很久以前的一天，Martin 在跟好友的交流中悟到了一种很棒的架构设计。他总结了一下，然后告诉了好友，好友说，这不是新鲜东西，早有人总结了，叫做 SOA。

Martin 很高兴，开始在公司内外推广 SOA。结果，不停有人质疑和挑战他。

你这不是 SOA 吧？SOA 这里应该是如此这般的。对，这里我对 SOA 的理解是这样的。你看，这本 SOA 的书说的和你说的有出入。粒度？SOA 没有谈到这个呀，你这不是 SOA。分层跟 SOA 没有关系，你为什么要说这个呢？…

Martin 没办法，心一横，老子就叫它 Martin's SOA。老子发明的词，老子就是最高权威，有最终解释权。还有谁不服？

同事们一看，这思想本身很不错，值得推广，但叫 Martin's SOA 太没品了吧？还是要取个好一点的名字，最好还能跟 SOA 有某种暗示传承。干脆就叫 Microservices 好了，又新，又有服务含在其中。

Martin 忿忿地接受了这个建议，心里想着：娘的，明明就是 SOA，一群**非要逼我取个新名字。

后来 Martin 发现每次提一个东西就会收到旧恶傻势力对解释权的挑战，所以每次要提一个什么概念，都去发明一个新词，免得一群人在那一边质疑挑战，一边大谈“我的理解”。

这就是微服务、敏捷、精益企业、持续集成、持续交付背后的故事。

一个名词产生之后，命名者的解释权就会随着时间而弱化（比如 Cooper 发明的 Persona 就被无数设计师乱用）。敏捷已经有点烂了，等微服务也烂了，我们还会发明新词。

实在没辙，都是被逼的啊。

❞

故事二：

❝

话说1979年，又是一个春天，莆田乡下的赤脚医生吴大牛被改革的春风吹的心潮澎湃，说干就干，吴大牛趁着夜色朦胧找大队支书汇报了汇报思想，第二天就承包了村卫生室，开启了自己的在医疗圈的传奇历程。

乡村诊所大家都知道，没什么复杂的东东，房子只有一间，一个大柜台中间隔开，一半是诊疗兼候诊区，一半是药房，看病就直接找医生，如果前面有人就自己找个位子坐下，排队等一会，秩序倒也井然，看完病了医生直接给抓药，然后下一个继续，也不需要护士和药剂师，吴大牛一个人全部包办。

辛辛苦苦忙碌了十年，时间来到了八九年，又是一个春天，昔日的单身汉吴大牛已成为十里八乡的知名人物，媳妇娶上了不说，家里还增加了一对双胞胎儿子，二层的小洋房也甚是气派。可是也有烦心事，尽管乡村诊所扩大到了两间，媳妇还偶尔能去帮帮忙，但是医生还是只有自己一个，天天从早忙到晚挣的都是一份钱，想多挣点怎么办？吴大牛日思夜想，还真给他想出来一招，怎么办，扩大规模，多招几个医生一起干。原来吴大牛只能治头疼脑热和跌打损伤，现在新招了一个医科大学的毕业生刘小明专治感冒发烧，又从邻村请来了老大夫李阿花专治妇科病，现在一个普通的小诊所就变成了有三个独立科室加一个公共药房（吴大牛媳妇负责）的小医院了，吴大牛是外科主任兼院长，收入那可比之前翻了三番。人逢喜事精神爽，大牛院长请县里的书法名家为新医院书写了牌匾--“博爱医院”，挑了一个黄道吉日正式挂了上去。

一晃十年过去了，又是一个春天，吴大牛的博爱医院已经发展到了内科外科妇科五官科骨科生殖科六个科室，每个科室3到5名医生不等，也耗费巨资购进了血液化验B超等先进仪器，大牛院长也早已脱离了医疗一线，成为了专职的管理者，但是医院的大事小事大家都找他，就这三十多号员工搞的他每天是焦头烂额，想再扩大规模实在是有心无力了。要说还是大学生有水平，老部下刘小明给大牛院长献了一计，把各个科室独立出去，让各个科室主任自己管理，大牛院长只管科室之间的协调和医院发展的大事，这样既能调动基层的积极性，又能把大牛院长解放出来扩大生产抓大事谋大事，岂不妙哉？就这样，博爱医院的新一轮改革轰轰烈烈的展开了。

又是一个十年，又是一个春天，大牛院长已成为本地知名的企业家，博爱医院也发展到了二十三个科室数百名员工，发展中也出现了新问题，由于各个科室独立挂号、收费、化验，有的科室整天忙忙碌碌效益好，有的科室就相对平庸些，连分到的各种检查仪器都不能满负荷运行，整个医院养了不少闲人。这时候大牛院长视野也开阔了，请来了管理专家进行了顶层设计，把原来分散到各个科室的非核心服务全部收归集中管理，把原来二十三个挂号窗口整合为十个，二十三个收费窗口整合为八个，集中布设在一楼大厅为全院服务，还把分散在各个科室的检查仪器集中起来成立独立的检验科，也为全院服务，这样人人有活干，整个医院的服务能力又上了一个新台阶，这轮改革后博爱医院通过了各级部门的鉴定成为了远近驰名的三甲医院，吴大牛也摇身一变成为了博爱集团的CEO兼董事长，下一步就准备IPO上市了。

说到这里大家可能有点糊涂，这个跟微服务有嘛关系？大牛诊所的1.0阶段就相当于软件开发的单体结构，一个程序员打天下，从头编到尾，很难做大做强。大牛诊所的2.0阶段就相当于软件开发的垂直结构，各科室按照业务划分，很容易横向扩展。博爱医院的1.0阶段就相当于软件开发的SOA结构，除了药房（数据库）外各个服务独立提供（科室主任负责），但需要大牛院长（ESB总线）来协调。博爱医院的2.0阶段就相当于软件开发的微服务结构，公共服务院内共享，科室主任管理功能弱化（只管医生业务），优点是扩容方便，哪个部门缺人直接加，不用看上下游，资源利用率高，人员和设备效率高。

❞

微服务就是将一个单体架构的应用按业务划分为一个个的独立运行的程序即服务，它们之间通过 HTTP 协议进行通信（也可以采用消息队列来通信，如 RabbitMQ，Kafaka 等），可以采用不同的编程语言，使用不同的存储技术，自动化部署（如 Jenkins）减少人为控制，降低出错概率。服务数量越多，管理起来越复杂，因此采用集中化管理。例如 Eureka，Zookeeper 等都是比较常见的服务集中化管理框架。

**微服务是一种架构风格，架构就是为了解耦，实际使用的是分布式系统开发。**一个大型的复杂软件应用，由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好的完成该任务。

❝

「一句话总结：微服务是 SOA 发展出来的产物，它是一种比较现代化的细粒度的 SOA 实现方式。」

❞

微服务设计原则

AKF 拆分原则

业界对于可扩展的系统架构设计有一个朴素的理念，就是：通过加机器可以解决容量和可用性问题（如果一台不行就两台）。

用个段子描述就是：世界上没有什么事是一顿烧烤解决不了的，如果有，那就两顿。

《The Art of Scalability》一书提出了一个系统的可扩展模型——AKF 可扩展立方。这个立方体中沿着三个坐标轴设置分别为 X，Y，Z。

❝

一个叫 AKF 的公司的技术专家抽象总结的应用扩展的三个维度。理论上按照这三个扩展模式，可以将一个单体系统，进行无限扩展。

❞

Y 轴

就是我们所说的微服务的拆分模式，就是基于不同的业务拆分。Y 轴扩展会将庞大的整体应用拆分为多个服务。每个服务实现一组相关的功能，如商品管理、订单管理、用户管理等。

X 轴

X 轴扩展指得是水平复制，通过绝对平等地复制服务与数据，以解决容量和可用性的问题。很好理解，就是将单体系统多运行几个实例，成为集群加负载均衡的模式。

Z 轴

Z 轴扩展通常是指基于请求者或用户独特的需求，进行系统划分，并使得划分出来的子系统是相互隔离但又是完整的。以生产手机的工厂来举例：苹果公司为了发展在中国的业务，或者利用中国的廉价劳动力，在中国建立一个完整的子工厂，与美国工厂一样，负责完整的手机生产。这就是一种 Z 轴扩展。

❝

场景说明：比如单体打车应用，一个集群撑不住时，分了多个集群，后来用户激增还是不够用，经过分析发现是乘客和车主访问量很大，就将打车应用拆成了三个，分别为乘客服务、车主服务、支付服务。三个服务的业务特点各不相同，独立维护，各自都可以再次按需扩展。我们可以水平扩展三个服务，形成各自服务的集群模式。实在不行最后根据北上广热门地区划分为多份，你在哪个城市打车，就给你展示哪个城市的司机数据分区。

❞

前后端分离原则

以前的 Java Web 项目大多都是程序员既当爹又当妈，既搞前端，又搞后端。随着时代的发展，渐渐的许多大中小公司开始把前后端的界限分的越来越明确，前端工程师只管前端的事情，后端工程师只管后端的事情。正所谓术业有专攻，大中型公司需要专业人才，小公司需要全才，但是对于个人职业发展来说，前后端需要分离，毕竟一个人如果什么都会，那么他可能什么都不精。

未分离

在前后端不分离的应用模式中，前端页面看到的效果都是由后端控制，由后端渲染页面或重定向，也就是后端需要控制前端的展示，前端与后端的耦合度很高。

这种应用模式比较适合纯网页应用，但是当后端对接 App 时，App 可能并不需要后端返回一个 HTML 网页，而仅仅是数据本身，所以后端原本返回网页的接口不再适用于前端 App 应用，为了对接 App 后端还需再开发一套接口。

该时期代表：Servlet + Jsp + JavaBean

<body>
   <%
       request.setCharacterEncoding("utf-8");
       String username = request.getParameter("username");
       System.out.print(username);
   %>
</body>

半分离

前后端半分离，前端负责开发页面，通过接口（Ajax）获取数据，采用 Dom 操作对页面进行数据绑定，最终是由前端把页面渲染出来。步骤如下：

  1. 打开 WEB，加载基本资源，如 CSS，JS 等；
  2. 发起一个 Ajax 请求再到服务端请求数据，同时展示 Loading；
  3. 得到 Json 格式的数据后再根据逻辑选择模板渲染出 DOM 字符串；
  4. 将 DOM 字符串插入页面中渲染出 DOM 结构；

然而，在这种架构下，还是存在明显的弊端的。最明显的有如下几点：

  1. JS 存在大量冗余，在业务复杂的情况下，页面的渲染部分的代码，非常复杂；
  2. 在 Json 返回的数据量比较大的情况下，渲染的十分缓慢，会出现页面卡顿的情况；
  3. 资源消耗严重，在业务复杂的情况下，一个页面可能要发起多次 HTTP 请求才能将页面渲染完毕。PC 端建立多次 HTTP 请求也没啥。这里需要考虑一下移动端的感受。

该时期代表：SSM（Spring + SpringMVC + Mybatis）和 SSH（Spring + Struts2 + Hibernate）

分离

在前后端分离的应用模式中，后端仅返回前端所需的数据，不再渲染 HTML 页面，不再控制前端的效果。至于前端用户看到什么效果，从后端请求的数据如何加载到前端中，都由前端自己决定，网页有网页的处理方式，App 有 App 的处理方式，但无论哪种前端，所需的数据基本相同，后端仅需开发一套逻辑对外提供数据即可。

浏览器不再直接请求 JSP 的 API，而是：

  1. 浏览器请求服务器端的 NodeJS；
  2. NodeJS 再发起 HTTP 去请求后端；
  3. 后端依然原样 API 输出 JSON 给 NodeJS；
  4. NodeJS 收到 JSON 后再渲染出 HTML 页面；
  5. NodeJS 直接将 HTML 页面 flush 到浏览器；

这样，浏览器得到的就是普通的 HTML 页面，而不用再发 Ajax 去请求服务器了。

该时期代表：VueJS、AngularJS、ReactJS

总结

从经典的 Servlet + Jsp + JavaBean 的 MVC 时代，到 SSM（Spring + SpringMVC + Mybatis）和 SSH（Spring + Struts2 + Hibernate）的 Java 框架时代，再到前端框架（VueJS、AngularJS、ReactJS）为主的 MVVM 时代，然后是 Nodejs 引领的全栈时代，技术和架构一直都在进步。创新之路不会止步，无论是前后端分离模式还是其他模式，都是为了更方便地解决需求，但它们都只是一个“中转站”。前端项目与后端项目是两个项目，放在两个不同的服务器，需要独立部署，两个不同的工程，两个不同的代码库，不同的开发人员。前端只需要关注页面的样式与动态数据的解析及渲染，而后端专注于具体业务逻辑。

  • 前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验优化效果更好。
  • 前后端分离模式下，前后端交互界面更清晰，就剩下了接口模型，后端的接口简洁明了，更容易维护。
  • 前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支持多个前端：例如：微信 h5 前端、PC 前端、安卓前端、IOS 前端。

无状态服务

对于无状态服务，首先说一下什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务。

这个无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。

场景说明：例如我们以前在本地内存中建立的数据缓存、Session 缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。

也就是对同一个 url 请求没有上下文关系。举个生活中的例子：

❝

比如空调遥控器，你按上下调整温度时，空调温度设定值会变化，遥控器信号到空调是单向传输。现在空调显示温度 20 度，遥控器 20 度。如果遥控器与空调之间是有状态的，假设你离开空调接收范围调整了遥控器温度，变成 19，那回到范围内你按一次升高一度，基于原先温度状态，遥控器给空调发送一个“提高1度”的指令，就会出现遥控器提高到 20，而空调变成21。如果要空间与空调之前是无状态的，假设你离开空调接收范围调整了遥控器温度，变成 19，那回到范围内你按一次升高一度，遥控器给空调发送一个“设定温度值20”，这样两者最终还是相同的值。

❞

Restful 通信风格

基于**“无状态通信原则”**，在这里我们直接推荐一个实践优选的 Restful 通信风格 ，因为他有很多好处：

  • 无状态协议 HTTP，具备先天优势，扩展能力很强。例如需要安全加密时，有现成的成熟方案 HTTPS 可用。
  • JSON 报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好。
  • 语言无关，各大热门语言都提供成熟的 Restful API 框架，相对其他的一些 RPC 框架生态更完善。

CAP 原则与 BASE 理论

CAP 原则

CAP 原则又称 CAP 定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

CAP 由 Eric Brewer 在 2000 年 PODC 会议上提出。该猜想在提出两年后被证明成立，成为我们熟知的 CAP 定理。CAP 三者不可兼得。

特性 定理
Consistency 「一致性」，也叫做数据原子性，系统在执行某项操作后仍然处于一致的状态。在分布式系统中，更新操作执行成功后所有的用户都应该读到最新的值，这样的系统被认为是具有强一致性的。等同于所有节点访问同一份最新的数据副本。
Availability 「可用性」，每一个操作总是能够在一定的时间内返回结果，这里需要注意的是"一定时间内"和"返回结果"。一定时间内指的是在可以容忍的范围内返回结果，结果可以是成功或者是失败，且不保证获取的数据为最新数据。
Partition tolerance 「分区容错性」，分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障。

取舍策略

CAP 三个特性只能满足其中两个，那么取舍的策略就共有三种：

  • 「CA without P」：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃 P 的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。
  • 「CP without A」：如果不要求A（可用），相当于每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长（也就是等待数据同步完才能正常访问服务），一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。设计成 CP 的系统其实不少，最典型的就是分布式数据库，如 Redis、HBase 等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。
  • 「AP without C」：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。典型的应用就如某米的抢购手机场景，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。

总结

现如今，对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，节点只会越来越多，所以节点故障、网络故障是常态，因此「分区容错性」也就成为了一个分布式系统必然要面对的问题。那么就只能在 C 和 A 之间进行取舍。但对于传统的项目就可能有所不同，拿银行的转账系统来说，涉及到金钱的对于数据一致性不能做出一丝的让步，C 必须保证，出现网络故障的话，宁可停止服务，可以在 A 和 P 之间做取舍。而互联网非金融项目普遍都是基于 AP 模式。

总而言之，没有最好的策略，好的系统应该是根据业务场景来进行架构设计的，只有适合的才是最好的。

BASE 理论

CAP 理论已经提出好多年了，难道真的没有办法解决这个问题吗？也许可以做些改变。比如 C 不必使用那么强的一致性，可以先将数据存起来，稍后再更新，实现所谓的 “最终一致性”。

这个思路又是一个庞大的问题，同时也引出了第二个理论 BASE 理论。

❝

BASE：全称 Basically Available（基本可用），Soft state（软状态），和 Eventually consistent（最终一致性）三个短语的缩写，来自 ebay 的架构师提出。

❞

BASE 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于 CAP 定理逐步演化而来的。其核心思想是：

❝

既然无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

❞

Basically Available（基本可用）

基本可用是指分布式系统在出现故障的时候，允许损失部分可用性（例如响应时间、功能上的可用性）。需要注意的是，基本可用绝不等价于系统不可用。

  • 响应时间上的损失：正常情况下搜索引擎需要在 0.5 秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了 1~2 秒。
  • 功能上的损失：购物网站在购物高峰（如双十一）时，为了保护系统的稳定性，部分消费者可能会被引导到一个降级页面。

Soft state（软状态）

什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种 “硬状态”。

软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据会有多个副本，允许不同副本数据同步的延时就是软状态的体现。

Eventually consistent（最终一致性）

系统不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保持数据一致性。从而达到数据的最终一致性。这个时间期限取决于网络延时，系统负载，数据复制方案设计等等因素。

实际上，不只是分布式系统使用最终一致性，关系型数据库在某个功能上，也是使用最终一致性的，比如备份，数据库的复制都是需要时间的，这个复制过程中，业务读取到的值就是旧值。当然，最终还是达成了数据一致性。这也算是一个最终一致性的经典案例。

总结

总的来说，BASE 理论面向的是大型高可用可扩展的分布式系统，和传统事务的 ACID 是相反的，它完全不同于 ACID 的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间是不一致的。

微服务架构带来的问题

客户端如何访问服务？

传统的开发方式，所有的服务都是本地的，客户端可以直接调用，现在按功能拆分成独立的服务，客户端如何访问？

后台有 N 个服务，前台就需要管理 N 个服务，一个服务下线/更新/升级，前台就要重新部署，这明显不符合我们拆分的理念，另外，N 个服务的调用也是一个不小的网络开销。还有一般微服务在系统内部，通常是无状态的，用户登录信息和权限管理最好有一个统一的地方维护管理（OAuth2）。

所以，一般在后台 N 个服务和客户端之间一般会一个代理（API Gateway），作用如下：

  • 提供统一服务入口，聚合接口使得服务对调用者透明，客户端与后端的耦合度降低
  • 聚合后台服务，节省流量，提高性能，提升用户体验
  • 提供安全、流控、过滤、缓存、计费、监控等 API 管理功能

服务之间如何通信？

因为服务都是独立部署的，所以通信也就成了问题，不过好在业界已经有很多成熟的解决方案，比如：

  • 同步通信：
    • REST（JAX-RS，Spring Boot）
    • RPC（Dubbo，Thrift）
  • 异步通信：
    • RabbitMQ，Kafka

这么多服务如何查找？

在微服务架构中，为了高可用，普遍采用集群方式构建服务。一个服务可能随时下线，也可能应对临时访问压力增加新的服务节点。

服务之间如何相互感知？服务如何管理？这就是服务发现的问题了。基本都是通过类似 ZooKeeper 等类似技术做服务注册信息的分布式管理。当服务上线时，服务提供者将自己的服务信息注册到 ZooKeeper（或类似框架），并通过心跳维持长连接，实时更新连接信息。服务调用者通过 ZooKeeper 寻址，找到一个服务，还可以将服务信息缓存在本地以提高性能。当服务下线时，ZooKeeper 会发通知给服务客户端。

服务挂了怎么办？

在微服务架构中，一个请求需要调用多个服务是非常常见的。如客户端访问 A 服务，而 A 服务需要调用 B 服务，B 服务需要调用 C 服务，由于网络原因或者自身的原因，如果 B 服务或者 C 服务不能及时响应，A 服务将处于阻塞状态，直到 B 服务 C 服务响应。此时若有大量的请求涌入，容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，造成连锁反应，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。

雪崩是系统中的蝴蝶效应导致，其发生的原因多种多样，从源头我们无法完全杜绝雪崩的发生，但是雪崩的根本原因来源于服务之间的强依赖，所以我们可以提前评估做好服务容错。解决方案大概可以分为以下几种：

  • 请求缓存：支持将一个请求与返回结果做缓存处理；
  • 请求合并：将相同的请求进行合并然后调用批处理接口；
  • 请求限流：当请求过多时，可能会拖垮整个网站，通常会采取限流措施，降低机器的负载；
  • 服务隔离：限制调用分布式服务的资源，某一个调用的服务出现问题不会影响其他服务调用；
  • 服务熔断：牺牲局部服务，保全整体系统稳定性的措施；
  • 服务降级：服务熔断以后，客户端调用自己本地方法返回缺省值。

微服务架构生态体系

服务网关

随着微服务的不断增多，不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务通信可能出现：

  • 客户端会多次请求不同的微服务，增加了客户端的复杂性
  • 存在跨域请求，在一定场景下处理相对复杂
  • 身份认证问题，每个微服务需要独立身份认证
  • 难以重构，随着项目的迭代，可能需要重新划分微服务
  • 某些微服务可能使用了防火墙/浏览器不友好的协议，直接访问会有一定的困难

针对这些问题，API网关顺势而生。

API 网关直面意思是将所有 API 调用统一接入到 API 网关层，由网关层统一接入和输出。一个网关的基本功能有：统一接入、安全防护、协议适配、流量管控、长短连接支持、容错能力。有了网关之后，各个 API 服务提供团队可以专注于自己的的业务逻辑处理，而 API 网关更专注于安全、流量、路由等问题。

服务调用

在微服务架构中，通常存在多个服务之间的远程调用的需求。目前主流的远程调用技术有基于 HTTP 的 RESTful 接口和基于 TCP 的 RPC 协议。以上两种都属于同步通信，还有基于队列模式的异步通信。

  • REST（Representational State Transfer）：一种 HTTP 调用的格式，更标准，更通用，无论哪种语言都支持 http 协议。
  • RPC（Remote Promote Call）：一种进程间通信方式，允许像调用本地服务一样调用远程服务。RPC 框架的主要目标就是让远程服务调用更简单、透明。RPC 框架负责屏蔽底层的传输方式、序列化方式和通信细节。开发人员在使用的时候只需要了解谁在什么位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。

比较项 REST RPC
通讯协议 HTTP 一般使用 TCP
性能 略低 较高
灵活度 高 低
应用 微服务架构 SOA 架构

服务治理

服务治理就是进行服务的自动化管理，其核心是服务的自动注册与发现。

  • 「服务注册」：服务实例将自身服务信息注册到注册中心。
  • 「服务发现」：服务实例通过注册中心，获取注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。
  • 「服务剔除」：服务注册中心将出问题的服务自动剔除到可用列表之外，使其不会被调用到。

负载均衡

服务高可用的保证手段，为了保证高可用，每一个微服务都需要部署多个服务实例来提供服务，此时就需要根据不同的负载均衡策略对服务进行调用。

负载均衡策略

轮询策略

实现原理：轮询策略表示每次都顺序取下一个 provider，比如一共有 5 个 provider，第 1 次取第 1 个，第 2 次取第 2 个，第 3 次取第 3 个，以此类推。

权重轮询策略

实现原理：

  • 根据每个 provider 的响应时间分配一个权重，响应时间越长，权重越小，被选中的可能性越低。
  • 原理：一开始为轮询策略，并开启一个计时器，每 30 秒收集一次每个 provider 的平均响应时间，当信息足够时，给每个 provider 附上一个权重，并按权重随机选择 provider，高权越重的 provider 会被高概率选中。

随机策略

实现原理：从 provider 列表中随机选择一个。

最少并发数策略

实现原理：选择正在请求中的并发数最小的 provider，除非这个 provider 在熔断中。

重试策略

实现原理：其实就是轮询策略的增强版，轮询策略服务不可用时不做处理，重试策略服务不可用时会重新尝试集群中的其他节点。

可用性敏感策略

实现原理：过滤性能差的 provider

  • 第一种：过滤掉在 Eureka 中处于一直连接失败的 provider。
  • 第二种：过滤掉高并发（繁忙）的 provider。

区域敏感性策略

实现原理：

  • 以一个区域为单位考察可用性，对于不可用的区域整个丢弃，从剩下区域中选可用的 provider。
  • 如果这个 ip 区域内有一个或多个实例不可达或响应变慢，都会降低该 ip 区域内其他 ip 被选中的权 重。

服务容错

在微服务中，一个请求经常会涉及到调用多个服务，如果其中某个服务不可用，没有做服务容错的话，极有可能会造成一连串的服务不可用，这就是雪崩效应。最终的结果就是：一个服务不可用，导致一系列服务的不可用。

造成雪崩的原因可以归结为以下三点：

  • 服务提供者不可用（硬件故障，程序 BUG，缓存击穿，用户大量请求等）
  • 重试加大流量（用户重试，代码逻辑重试）
  • 服务消费者不可用（同步等待造成的资源耗尽）

我们没法预防雪崩效应的发生，只能尽可能去做好容错。服务容错的三个核心思想是：

  • 不被外界环境影响
  • 不被上游请求压垮
  • 不被下游响应拖垮

链路追踪

随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要对一次请求涉及的多个服务链路进行日志记录，性能监控等等。单纯的理解链路追踪，就是指一次任务的开始到结束，期间调用的所有系统及耗时（时间跨度）都可以完整记录下来。

链路追踪系统做好了，链路数据有了，借助前端解析和渲染工具，可以达到下图中的效果：

配置中心

配置文件是我们再熟悉不过的，在微服务系统中，每个微服务不仅仅只有代码，还需要「连接其他资源」，例如数据库的配置或功能性的开关 MySQL、Redis 、Security 等相关的配置。除了项目运行的基础配置之外，还有一些配置是与我们业务有关系的，比如说七牛存储、短信和邮件相关，或者一些业务上的开关。

但是随着微服务系统的不断迭代，整个微服务系统可能会成为一个「网状结构」，这个时候就要考虑整个微服务系统的「扩展性、伸缩性、耦合性」等等。其中一个很重要的环节就是「配置管理」的问题。

常规配置管理解决方案缺点：

  • 硬编码（需要修改代码、繁琐、风险大）
  • properties 或者 yml（集群环境下需要替换和重启）
  • xml（重新打包和重启）

由于常规配置管理有很大的缺点，所以采用 Spring Cloud Config 或 Consul 或 Apollo 或 Nacos 等配置中心「集中式」的来管理「每个服务」的配置信息。

安全认证

从单体应用架构到分布式应用架构再到微服务架构，应用的安全访问在不断的经受考验。为了适应架构的变化、需求的变化，身份认证与鉴权方案也在不断的变革。面对数十个甚至上百个微服务之间的调用，如何保证高效安全的身份认证？面对外部的服务访问，该如何提供细粒度的鉴权方案？

David Borsos 在伦敦的微服务大会上提出了四种解决方案：

单点登录（SSO）

这种方案意味着每个面向用户的服务都必须与认证服务交互，这会产生大量非常琐碎的网络流量和重复的工作，随着微服务应用的增多，这种方案的弊端会更加明显。

分布式 Session 方案

分布式会话方案原理主要是将关于用户认证的信息存储在共享存储中，且通常由用户会话作为 Key 来实现的简单分布式哈希映射。当用户访问微服务时，用户数据可以从共享存储中获取。这种方案的缺点在于共享存储需要一定保护机制，因此需要通过安全连接来访问，这时解决方案的实现就通常具有相当高的复杂性了。

客户端 Token 方案

令牌在客户端生成，由身份验证服务进行签名，并且必须包含足够的信息，以便可以在所有微服务中建立用户身份。令牌会附加到每个请求上，为微服务提供用户身份验证，这种解决方案的安全性相对较好，但身份验证注销是一个大问题，缓解这种情况的方法可以使用短期令牌和频繁检查认证服务等。对于客户端令牌的编码方案，David Borsos 更喜欢使用 JSON Web Tokens（JWT），它足够简单且库支持程度也比较好。

客户端 Token 与 API 网关结合

这个方案意味着所有请求都通过网关，从而有效地隐藏了微服务。 在请求时，网关将原始用户令牌转换为内部会话 ID 令牌。在这种情况下，注销就不是问题，因为网关可以在注销时撤销用户的令牌。

总结

在微服务架构下，我们更倾向于 David Borsos 所建议的 JWT 方案，将 OAuth2 和 JWT 结合使用，OAuth2 一般用于第三方接入的场景，管理对外的权限，所以比较适合和 API 网关结合，针对于外部的访问进行鉴权（当然，底层 Token 标准采用 JWT 也是可以的）。

JWT 更加轻巧，在微服务之间进行认证&鉴权已然足够，并且可以避免和身份认证服务直接打交道。当然，从能力实现角度来说，类似于分布式 Session 在很多场景下也是完全能满足需求，具体怎么去选择鉴权方案，还是要结合实际的需求来。

微服务架构技术支持

Spring Cloud

  • Spring Cloud Netflix Eureka：服务注册中心。
  • Spring Cloud Zookeeper：服务注册中心。
  • Spring Cloud Consul：服务注册和配置管理中心。
  • Spring Cloud Netflix Ribbon：客户端负载均衡。
  • Spring Cloud Netflix Hystrix：服务容错保护。
  • Spring Cloud Netflix Feign：声明式服务调用。
  • Spring Cloud OpenFeign(可替代 Feign)：OpenFeign 是 Spring Cloud 在 Feign 的基础上支持了 Spring MVC 的注解，如 @RequesMapping等等。OpenFeign 的 @FeignClient 可以解析 SpringMVC 的 @RequestMapping 注解下的接口，并通过动态代理的方式产生实现类，实现类中做负载均衡并调用其他服务。
  • Spring Cloud Netflix Zuul：API 网关服务，过滤、安全、监控、限流、路由。
  • Spring Cloud Gateway(可替代 Zuul)：Spring Cloud Gateway 是 Spring 官方基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技术开发的网关，Spring Cloud Gateway 旨在为微服务架构提供一种简单而有效的统一的 API 路由管理方式。Spring Cloud Gateway 作为 Spring Cloud 生态系中的网关，目标是替代 Netflix Zuul，其不仅提供统一的路由方式，并且基于 Filter 链的方式提供了网关基本的功能，例如：安全，监控/埋点，和限流等。
  • Spring Cloud Security：安全认证。
  • Spring Cloud Config：分布式配置中心。配置管理工具，支持使用 Git 存储配置内容，支持应用配置的外部化存储，支持客户端配置信息刷新、加解密配置内容等。
  • Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与 Spring Cloud Config 联合实现热部署。
  • Spring Cloud Stream：消息驱动微服务。
  • Spring Cloud Sleuth：分布式服务跟踪。
  • Spring Cloud Alibaba Nacos：阿里巴巴开源产品，一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
  • Spring Cloud Alibaba Sentinel：面向分布式服务架构的轻量级流量控制产品，把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
  • Spring Cloud Alibaba RocketMQ：一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。
  • Spring Cloud Alibaba Dubbo：Apache Dubbo™ 是一款高性能 Java RPC 框架，用于实现服务通信。
  • Spring Cloud Alibaba Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。
  • Spring Cloud Alibaba OSS：阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务。您可以在任何应用、任何时间、任何地点存储和访问任意类型的数据。
  • Spring Cloud Alibaba SchedulerX：阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。
  • Spring Cloud Alibaba SMS：覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。

其他大哥

  • RibbitMQ：RabbitMQ 是部署最广泛的开源消息中间件。是实现了高级消息队列协议（AMQP）的开源消息中间件。
  • Kafka：Kafka 是由 Apache 软件基金会开发的一个开源流处理平台，由Scala和Java编写。Kafka 是一种高吞吐量的分布式发布订阅消息系统。
  • Redis：Redis（Remote Dictionary Server )，即远程字典服务，是一个开源的使用 ANSI C 语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value 数据库，并提供多种语言的 API。
  • MongoDB：MongoDB 是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。它支持的数据结构非常松散，是类似 json 的 bson 格式，因此可以存储比较复杂的数据类型。
  • Elasticsearch：Elasticsearch 是一个基于 Lucene 的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于 RESTful web 接口。Elasticsearch 是最受欢迎的企业搜索引擎，其次是 Apache Solr，也是基于 Lucene。
  • MySQL：MySQL 是一种开放源代码的关系型数据库管理系统（RDBMS），免费、简单、占资源少、强大好用。
  • Oracle：世界上最昂贵的数据库，一般金融系统使用居多。
  • FastDFS：FastDFS是一个开源的轻量级分布式文件系统，它对文件进行管理，功能包括：文件存储、文件同步、文件访问（文件上传、文件下载）等，解决了大容量存储和负载均衡的问题。特别适合以文件为载体的在线服务，如相册网站、视频网站等等。
  • HDFS：Hadoop 生态组件，可以支持千万级的大型分布式文件系统。
  • XX-JOB：轻量级分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线，开箱即用。
  • TX-LCN：分布式事务解决防范，LCN 并不生产事务，LCN 只是本地事务的搬用工（事务的协调工）。LCN 是一个高性能的分布式事务框架，兼容 Dubbo、Spring Cloud，支持 RPC 框架拓展，支持各种 ORM 框架、NoSQL、负载均衡、事务补偿。
  • Zipkin：Twitter 公司开发贡献的一款开源的分布式实时数据追踪系统（Distributed Tracking System），基于 Google Dapper 的论文设计而来，其主要功能是聚集各个异构系统的实时监控数据。
  • Skywalking：Apache Skywalking 是一个开源的，用于收集、分析，聚合，可视化来自于不同服务和本地基础服务的数据的可观察的平台。特别为分布式系统而设计的数据观察和监控系统。
  • Apollo：携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
  • ConfigKeeper：随行付架构部基于 Spring Cloud 研发的分布式配置中心。与 Spring Boot、Spring Cloud 应用无缝兼容。
  • JWT：JSON Web Token（JWT）是一个非常轻巧的规范。这个规范允许我们使用 JWT 在用户和服务器之间传递安全可靠的信息。
  • Nginx：Nginx 是一款轻量级的 Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，其特点是占有内存少，并发能力强，中国大陆使用 Nginx 网站用户有：百度、淘宝、腾讯、京东、新浪、网易等。
  • Git：开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。
  • Docker：Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux 或 Windows 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。
  • Kubernetes：Kubernetes，简称 k8s，是用 8 代替 8 个字符“ubernete”而成的缩写。Kubernetes 脱胎于 Google 的 Borg 系统，是一个开源的功能强大的容器编排系统，用于管理云平台中多个主机上的容器化的应用，实现了容器集群的自动化部署、扩容以及运维的开源平台。Kubernetes 的目标是让部署容器化的应用简单并且高效。

本文采用 知识共享「署名-非商业性使用-禁止演绎 4.0 国际」许可协议。

大家可以通过 分类 查看更多关于 Spring Cloud 的文章。

🤗 您的点赞和转发是对我最大的支持。

📢 扫码关注 哈喽沃德先生「文档 + 视频」每篇文章都配有专门视频讲解，学习更轻松噢 ~

posted @ 2020-03-01 11:49  哈喽沃德先生  阅读(3544)  评论(7)  编辑  收藏  举报