http://doc.cocolian.cn/wechat/2018/10/08/prodev/
作者：凤凰牌老熊

大家好，今天分享的主题是“web服务的相关知识“，这个是做为一个系列来的，今天着重说两个方面，有部分不知道理解的准确与否，请大家也提建议一起讨论。
分享导图：
主要分享内容导图：

今天主要针对上面图里的web服务器和分布式发展两个方面介绍web服务的演进过程；

一、Web服务器

1.1 HOST主体

先说下时下一个web服务运行的host主体：

  1. 独立服务器： 机房里实实在在的物理服务器，也可以理解为高配版的pc机。
  2. vps (虚拟专用服务器）： 独立服务器通过虚拟化技术虚拟出多个专用服务器。
  3. 云服务ECS(Elastic Compute Service) ： 建立在服务器集群之上的，可以理解为，也是通过虚拟化技术整合多台独立服务器资源的弹性服务器。
  4. 虚拟主机：一个独立主机或者vps服务器上，可以运行多个站点的技术。

通俗的理解: 云服务可以看作是大酒店，独立服务器可以认为是酒店的房间，vps理解为房间的卧室，虚拟主机理解为卧室里一个床位。 你买了一个云服务，相当于你定了一个房间(这里只是比喻，这里并不一定是独立服务器），不够用随时加订，每一间卧室（vps)都可以睡觉，看电视，拉便便，但是虚拟主机就只能让你睡觉（部署站点用）。

1.2 应用场景

这些服务器应用场景，以下是个人的理解和总结：
服务器应用场景介绍：

  • 独立服务器：就是想要有自己的机房（比如大厂，企事业单位等）
  • 服务器租赁提供商：
  • 虚拟主机-企业网站，个人博客(可参照阿里云理解)；
  • vps-适用于小型Web应用、轻量应用等低负载、突发型应用场景(可参照理解阿里云已提供系统镜像，应用镜像两种)
  • 云服务(弹性服务)-企业应用，视频编码等高耗cpu负载的场景；

以上是主要的服务器类型，其实也是虚拟化，容器化技术的发展历史。

二、分布式的发展史

2.1 SOA阶段

分布式系统（确切地说，分布式计算机系统）已经从它开始的地方走了很长一段路。 一开始，一台计算机一次只能执行一项特定任务。如果我们需要并行完成多个任务，我们需要并行运行多台计算机。 但是并行运行它们不足以构建真正的分布式系统，因为它需要一种机制来在不同的计算机（或在这些计算机上运行的程序）之间进行通信。 这种跨多台计算机交换（共享）数据的要求触发了面向消息的通信的想法，其中两台计算机使用包装数据的消息共享数据。
如上所说，分布式系统实际指分布式计算系统，现在大数据的mapreduce以及流式计算其实都是分布式计算的一种。
最开始一个企业系统如下：
然后是多任务操作系统和个人计算机的时代。使用Windows，Unix，Linux操作系统，可以在同一台计算机上运行多个任务。 这允许分布式系统开发人员在通过消息传递连接的一台或几台计算机内构建和运行整个分布式系统，这导致了面向服务的体系结构（SOA），其中每个分布式系统都可以构建为集成一组服务，这些服务在一台计算机或多台计算机上运行，服务接口通过WSDL（用于SOAP）或WADL（用于REST）正确定义，服务使用者使用这些接口进行客户端实现。

2.2 web service的发展阶段

随着计算能力和存储价格的降低，全世界的组织开始使用分布式系统和基于SOA的企业IT系统，一旦服务或系统的数量增加，这些服务的点对点连接就不再可扩展和可维护，这导致了集中式“服务总线”的概念，该服务总线通过集线器类型架构互连所有不同的系统，这个组件被称为ESB（企业服务总线），它充当语言翻译者或中间人，他们是一群谈论不同语言但又希望彼此交流的人，在企业中，语言类似于消息传递协议和消息传递格式，不同的系统用于它们的通信，该模型的主要优点是每个系统都可以构建服务器端和客户端实现，而无需担心连接系统的协议。为了方便不同系统的通信和扩展，加入了企业总线ESB。这个阶段实际就是web service的发展阶段，到现在仍然有很多企业在用。

2.3 restful service

随着万维网的普及和模型的简单性，基于REST的通信变得比基于SOAP的通信模型更受欢迎，这导致了基于应用程序编程接口（API）的REST模型通信的发展。由于REST模型的简单性，需要在标准REST API实现之上实现安全性（身份验证和授权），缓存，限制和监视类型功能等功能，不是单独在每个API上实现这些功能，而是需要有一个通用组件来在API之上应用这些功能，这一要求引领了API管理平台的发展，如今它已成为任何分布式系统的核心功能之一。

2.4 分布式系统

分布式系统的大爆炸时刻，基于互联网的公司如Facebook，谷歌，亚马逊，Netflix，LinkedIn，Twitter变得如此之大，以至于他们想要构建跨越多个地理位置和多个数据中心的分布式系统，这些类型的要求使技术重点转移到一切开始的地方，工程师们开始考虑单个计算机和单个程序的概念。 他们不考虑将一台计算机视为一台计算机，而是考虑在同一台计算机中创建多台虚拟计算机的方法。这导致了虚拟机的想法，其中同一台计算机可以充当多台计算机并且并行运行它们，虽然这是一个很好的想法，但它并不是主机资源利用率的最佳选择。 运行多个操作系统需要额外的资源，这些资源在同一操作系统中运行时不需要。 这导致了容器的概念，其中使用相同的主机操作系统内核（Linux）在单独的运行时上运行多个程序及其所需的依赖性，这个概念在Linux操作系统上已有一段时间了，随着基于容器的应用程序部署的引入，它变得越来越流行并得到了很大的改进。容器可以与虚拟机相同，而不会产生单独操作系统的开销。

  • 可以将应用程序和所有相关依赖项放入容器映像中，并且可以在具有可以运行容器的主机操作系统的任何环境中运行，Docker和Rocket是2个流行的容器构建平台。

    2.5 微服务

    2.5.1 微服务简介

    这为Netflix，LinkedIn，Twitter等组织提供了基础框架，以构建他们要求苛刻的多区域，多数据中心应用平台； 然而，这并非没有复杂性。基于容器的部署的微型特性带来了跨多个容器的平台维护和编排的复杂性，随着微服务架构（MSA）的发明，单片应用程序被划分为更小的微服务块，这些微服务能够执行整个服务的给定功能并部署在容器中（在大多数情况下），这为分布式系统生态系统带来了一系列不同的要求，使系统最终保持一致并相互通信而没有太多复杂性。

2.5.2 微服务和单体应用的区别

有了docker这种容器技术，自然也就产生了容器管理，编排的需求； 这些要求最终帮助工程师构建了一个容器编排系统，可用于维护较大的基于容器的部署的一致性。 毫不奇怪，这个领域的突出技术来自谷歌，因为它的规模，他们构建了名为“Kubernetes”（a.k.a k8s）的容器编排平台，它成为大规模容器编排要求的事实标准，K8S允许工程师： 在大型集群中运行容器,将数据中心视为一台计算机, 服务之间的通信（在容器上运行）, 自动扩展，在多个服务之间进行负载平衡Kubernetes和docker使应用程序员的生活更轻松，他们不再想让自己的心思考虑它在不同环境中的表现（操作系统，DEV，TEST，PROD等），因为他构建的容器图像在所有环境中运行几乎相同，因为所有依赖关系都被打包到其中。

2.5.3 K8S简介

对于容器和编排框架，应该有一个管理这些服务器的团队，这意味着需要使用docker，kubernetes等技术来管理数据中心，以确保它对应用程序来说就像一台计算机一样。 而不是你这样做，其他人如何为你管理那部分，这正是无服务器架构所带来的，其中您的服务器将由亚马逊（Lambda），微软（Azure功能）或谷歌（云功能）等第三方云提供商进行管理。 现在，分布式系统将由应用程序员编程，而底层基础架构管理将由云提供商完成；

杂谈:

  • 另外，貌似今年比较火的一个service mesh(服务网格），微服务界的tcp/ip。
  • 附一个搞服务，常用的linux命令图：
  • Hadoop就是一个组件包，里面既有分布式计算的，又有分布式存储的，还有分布式管理的，分布式计算的就是MapReduce，分布式存储的就是hdfs；

  • mapreduce 本身也是分布式的，其实我觉得这样说吧，你可能把分布式和微服务做对立来看了。我觉的微服务是分布式的一个子集，分布式开始主要的目的是分散压力，微服务是分散功能，而mapreduce本身就是分散压力；

    三、名词释义

  • ADLS Connector：The ADLS Connector service provides key management for accessing Azure Data Lake Stores from CDH services.

  • Accumulo： The Apache Accumulo sorted, distributed key/value store is a robust, scalable, high performance data storage and retrieval system. This service only works with releases based on Apache Accumulo 1.6 or later.
  • Flume：Flume 从几乎所有来源收集数据并将这些数据聚合到永久性存储（如 HDFS）中。
  • HBase：Apache HBase 提供对大型数据集的随机、实时的读/写访问权限（需要 HDFS 和 ZooKeeper）。
  • HDFS：Apache Hadoop 分布式文件系统 (HDFS) 是 Hadoop 应用程序使用的主要存储系统。HDFS 创建多个数据块副本并将它们分布在整个群集的计算主机上，以启用可靠且极其快速的计算功能。
  • Hive：Hive 是一种数据仓库系统，提供名为 HiveQL 的 SQL 类语言。
  • Hue：Hue 是与包括 Apache Hadoop 的 Cloudera Distribution 配合使用的图形用户界面(需要 HDFS、MapReduce 和 Hive)。
  • Impala： Impala 为存储在 HDFS 和 HBase 中的数据提供了一个实时 SQL 查询接口。Impala 需要 Hive 服务，并与 Hue 共享 Hive Metastore。
  • Isilon： EMC Isilon is a distributed filesystem. Java KeyStore KMS The Hadoop Key Management Service with file-based Java KeyStore. Maintains a single copy of keys, using simple password-based protection. Requires CDH 5.3+. Not recommended for production use.
  • Kafka： Apache Kafka is publish-subscribe messaging rethought as a distributed commit log 。
  • Kudu： Kudu is a true column store for the Hadoop ecosystem.
  • MapReduce： Apache Hadoop MapReduce 支持对整个群集中的大型数据集进行分布式计算（需要 HDFS）。建议改用 YARN（包括 MapReduce 2）。包括 MapReduce 用于向后兼容性。
  • Oozie： Oozie 是群集中管理数据处理作业的工作流协调服务。
  • S3： Connector The S3 Connector Service securely provides a single set of AWS credentials to Impala and Hue. This enables Hue administrators to browse the S3 filesystem and define Impala tables backed by S3 data authorized to that AWS identity, and also enables Impala users to query S3-backed tables without directly providing AWS credentials, subject to having the proper permissions defined via Sentry. The S3 Connector only supports the S3A protocol. Sentry Sentry 服务存储身份验证政策元数据并为客户端提供对该元数据的并发安全访问。
  • Solr： Solr 是一个分布式服务，用于编制存储在 HDFS 中的数据的索引并搜索这些数据。
  • Spark： Apache Spark is an open source cluster computing system. This service runs Spark as an application on YARN. Spark (Standalone) This is the standalone version of the service which does not use YARN for resource management. Cloudera recommends using Spark on YARN instead of this standalone version.
  • Sqoop： 是一个设计用于在 Apache Hadoop 和结构化数据存储（如关系数据库）之间高效地传输大批量数据的工具。Cloudera Manager 支持的版本为 Sqoop 2。
  • YARN (MR2 Included)： Apache Hadoop MapReduce 2.0 (MRv2) 或 YARN 是支持 MapReduce 应用程序的数据计算框架（需要 HDFS）。
  • ZooKeeper： Apache ZooKeeper 是用于维护和同步配置数据的集中服务。

本文档来自支付产品技术交流群的聊天记录整理，由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息，请扫码关注“凤凰牌老熊”的微信公众号。 本群面向支付行业的有经验（2年以上）的产品经理、软件工程师、架构师等，提供交流平台。如想加入本群，请在本文评论中留言（不公开），说明所在的公司、负责的工作、入群分享的主题和时间。