Linux服务器 *** 作系统简介及版本介绍

Linux *** 作系统在服务器方面的应用越来越好。下面由我为大家整理了Linux服务器 *** 作系统的简介及版本介绍，希望对大家有帮助!

Linux服务器 *** 作系统简介及版本介绍

一、Linux服务器 *** 作系统简介

Linux服务器 *** 作系统和一般的Linux发行版有什么区别?考虑服务器硬件。服务器本质上是具有专门规格的计算机。例如，服务器硬件确保最大的正常运行时间，效率和安全性。此外，服务器平衡计算能力和功耗。类似地，Linux服务器 *** 作系统优先考虑安全性和资源消耗。

Linux服务器 *** 作系统向客户端设备提供内容。因此，服务器 *** 作系统提供了用于简单服务器创建的工具。由于服务器通常以命令行方式进行配置和运行，因此Linux服务器 *** 作系统的图形用户界面(GUI)不重要。

根据IDC，硬件销售数据表明，28%的服务器是基于Linux的。虽然有专用的Linux服务器 *** 作系统，还可以选择滚动安装版本。选择的关键是 *** 作系统应该能提供长期服务(LTS)迭代并支持安装所需的软件。LTS的发行版提供了稳定性和更长的支撑周期。

当选择Linux服务器 *** 作系统时，还要考虑使用用途。比如将Linux计算机用作媒体服务器与设置游戏服务器是不同的。

二、Linux服务器 *** 作系统版本介绍

1. Ubuntu Server

Ubuntu可以说是最知名的Linux *** 作系统。而且社区有大量的Ubuntu衍生产品，它是一个稳定的发行版。Ubuntu及其变体提供了优秀的用户体验。Ubuntu Server有两个版本：LTS和滚动版本。LTS的Ubuntu Server发行版拥有五年的支持周期。虽然非LTS的Ubuntu Server发行版支持周期不是五年，但也提供了九个月的安全和维护更新。

虽然Ubuntu和Ubuntu Server非常相似，但服务器提供了不同的组件。值得注意的是，Ubuntu Server提供了OpenStack Mitaka、Nginx和LXD。这些内容能满足系统管理员的需求。使用Ubuntu Server版，可以启动Web服务器、部署容器等。而且它是即开即用的服务器软件。

虽然Ubuntu LTS不是一个服务器发行版，但它也提供了五年的支持周期。我目前使用Ubuntu 16.04 LTS来运行专用的Plex服务器以及Linux游戏服务器。LTS发行版可以很好地作为Linux服务器 *** 作系统。只需自己安装服务器软件即可。

谁应该使用它：

如果你刚接触Linux或服务器 *** 作系统，Ubuntu是一个优秀的选择。Ubuntu仍然是最流行的Linux发行版之一，而且它对用户友好。因此，Ubuntu Server是一个梦幻般的入门级Linux服务器 *** 作系统。它作为媒体服务器、游戏服务器或电子邮件服务器是一流的选择。更高级的服务器设置也适合Ubuntu服务器，但它绝对是一个基本的服务器和新手用户的选择。

2. openSUSE

SUSE Linux于1993年首次推出。直到2015年，开源版本的openSUSE迁移到SUSE Linux Enterprise(SLE)。提供了两个openSUSE衍生版：Leap和Tumbleweed。Leap具有更长的发布周期，而Tumbleweed则是滚动发布版。Tumbleweed更适合高级用户使用其最新的软件包，比如Linux内核和SAMBA等。Leap版则有更好的稳定性和成熟度。两者都支持更新 *** 作系统。

企业客户不能承受不稳定、不成熟和未经测试的包。一切都必须严格测试，以确保业务不会出现问题，并导致损失。故Leap版可以确保企业客户的需求。

openSUSE算是一个梦幻般的Linux服务器 *** 作系统。openSUSE包含了用于自动测试的openQA，用于在多个平台上进行Linux映像部署的Kiwi，用于Linux配置的YaST以及全面的软件包管理器Open Build Service。早些时期，SUSE并没有像Redhat和Canonical那样提供免费的企业发行版，如CentOS和Ubuntu，直到Leap版的发布。SUSE官方称，Leap是一个替代Ubuntu、CentOS和Debian的生产服务器的优秀选择。以前openSUSE遵循9个月的发布周期，即每9个月发布一个新的主要版本。而Leap则遵循SLE的发布周期。

谁应该使用它：

openSUSE更适合于像系统管理员这样的强大用户。它是一个伟大的Web 服务器、家庭服务器或家庭服务器/ Web服务器组合。系统管理员可以从诸如Kiwi，YaST，OBS和openQA之类的工具中获益。openSUSE的多功能性使其成为最好的Linux服务器 *** 作系统之一。除了稳固的服务器功能外，openSUSE还提供了一个漂亮的桌面环境。

3. Oracle Linux

如果你在考虑Oracle Linux，这很正常。oracle Linux是由数据库巨头Oracle提供的Linux发行版。它有两个内核。其中一个内核特性是红帽兼容内核RHCK(Red Hat Compatible Kernel)，即提供了与Red Hat Enterprise Linux(RHEL)发行版相同的内核。Oracle Linux有认证，可以在联想、IBM和HP等大量硬件上工作。Oracle Linux提供了Ksplice特性，增强了内核的安全性。另外还支持Oracle、openstack、Linux容器和Docker。其品牌标识为Oracle企鹅。

Oracle Linux提供了技术支持，但需要付费。除非你在企业环境中运行Oracle Linux，否则不值得这么付出。如果需要构建公有云或私有云，Oracle Linux是一个优秀服务器 *** 作系统选择。

谁应该使用它：

Oracle Linux最适合数据中心或用于创建基于OpenStack的云。而更高级的家庭服务器用户和企业级设置也适合使用Oracle Linux。

4. 容器Linux(前身为CoreOS)

CoreOS于2016年更名为Container Linux。顾名思义，Container Linux是一个用于部署容器的Linux *** 作系统。它聚焦于简化容器的部署。容器Linux是提供了安全的、高可扩展的、支持容器部署的一流 *** 作系统。集群化的部署非常容易，其发行版包含了服务发现的方法。并提供了Kubernetes、docker和rkt的文档和支持。

但是，容器Linux没有提供包管理器。所有应用程序必须在容器中运行，因此容器化是强制必需的。然而，如果你正在使用容器，那么容器Linux是提供了容器及其集群等基础设施最好的Linux服务器。它提供了一个etcd工具，作为守护进程运行于集群中的每个计算机上。当然你也有安装的灵活性。除了内部部署安装外，您还可以在虚拟化介质(如Azure，VMware和Amazon EC2)上运行Container Linux。

谁应该使用它：

容器Linux最适合集群基础设施的服务器或容器化部署。这并不意味着它不是家庭服务器的选择。如果使用来自Plex的官方Docker镜像，Container Linux可以作为基本家庭媒体服务器或者是复杂集群设置的任何服务器。最终，如果你很喜欢容器，那么应该使用Container Linux。

补充：Linux服务器 *** 作系统如何选择

(1)Debian与Ubuntu的选择

Ubuntu是基于Debian所开发，可以简单地认为Ubuntu是Debian的功能加强版。与Debian相比，Ubuntu提供了更人性化系统配置，更强大的系统 *** 作以及比Debian更激进的软件更新。Ubuntu与Debian比较，可以认为Debian更趋向于保守一些，Ubuntu对新手友好度更高，上手更容易。用过Ubuntu的都会体会到它的易用，反之如果用过Ubuntu再换到别的系统，都会觉得不适应，Ubuntu真的很方便。

在此解释下Ubuntu的版本支持时间。Ubuntu普通版本只提供18个月的技术支持，过期则不管。LTS服务器版本提供长达五年的技术支持。Ubuntu 10.10是个普通版，现在已经过了支持周期了。如果你用了，很好，你会发现你安装不了任何软件，10.10的软件已经从Ubuntu软件源中被移除了。

所以建议大家选择12.04 LTS版，提供长达5年的技术支持，可以确保在静候相当长的一段时间内你的服务器可以继续收到系统升级补丁以及可用的软件源。

(2)Red Hat和Centos选择

Red Hat跟Centos就没那么多差别了。

Red Hat是付费 *** 作系统，你可以免费使用，但是如果要使用Red Hat的软件源并且想得到技术支持的话，是要像Windows那样掏钱的，所以大家可以理解为Linux中的Windows。这么做符合开源精神，免费使用，服务收费。

Centos是Red Hat的开源版本。一般在Red Hat更新之后，Centos会把代码中含有Red Hat专利的部分去掉，同时Red Hat中包含的种种服务器设置工具也一起干掉，然后重新编译就是Centos。

从某种意义上说，Centos几乎可以完完全全看成是Red Hat，这两个版本的rpm包都是可以通用的。

那么这样问题就简单了。如果你舍得花钱买技术支持，并且想得到完善的技术服务，请去买Red Hat的授权，你会得到如Windows一般强大的技术支持的。如果你只想用，什么付费技术支持什么专有软件都是浮云，那么用Centos吧。

服务发现就是服务提供者将自己提供的地址post或者update到服务中介，服务消费者从服务中介那里get自己想要的服务的地址。

但是有两个问题：

第一个问题：如果有一个服务提供者宕机，那么中介的key/value中会有一个不能访问的地址，该怎么办？

心跳机制： 服务提供者需要每隔5秒左右向服务中介汇报存活，服务中介将服务地址和汇报时间记录在zset数据结构的value和score中。服务中介需要每隔10秒左右检查zset数据结构，踢掉汇报时间严重落后的地址。这样就可以保证服务列表中地址的有效性。

第二个问题是服务地址变动时如何通知消费者。有两种解决方案。

第一种是轮询，消费者每隔几秒查询服务列表是否有改变。如果服务地址很多，查询会很慢。这时候可以引入服务版本号机制，给每个服务提供一个版本号，在服务变动时，递增这个版本号。消费者只需要轮询这个版本号的变动即可知道服务列表是否发生了变化。

第二种是采用pubsub。这种方式及时性要明显好于轮询。缺点是每个pubsub都会占用消费者一个线程和一个额外的连接。为了减少对线程和连接的浪费，我们使用单个pubsub广播全局版本号的变动。所谓全局版本号就是任意服务列表发生了变动，这个版本号都会递增。接收到版本变动的消费者再去检查各自的依赖服务列表的版本号是否发生了变动。这种全局版本号也可以用于第一种轮询方案。

CAP理论

CAP理论是分布式架构中重要理论

关于P的理解，我觉得是在整个系统中某个部分，挂掉了，或者宕机了，并不影响整个系统的运作或者说使用，而可用性是，某个系统的某个节点挂了，但是并不影响系统的接受或者发出请求，CAP 不可能都取，只能取其中2个。原因是

（1）如果C是第一需求的话，那么会影响A的性能，因为要数据同步，不然请求结果会有差异，但是数据同步会消耗时间，期间可用性就会降低。

（2）如果A是第一需求，那么只要有一个服务在，就能正常接受请求，但是对与返回结果变不能保证，原因是，在分布式部署的时候，数据一致的过程不可能想切线路那么快。

（3）再如果，同事满足一致性和可用性，那么分区容错就很难保证了，也就是单点，也是分布式的基本核心，好了，明白这些理论，就可以在相应的场景选取服务注册与发现了。

平时经常用到的服务发现的产品进行下特性的对比，首先看下结论：

补充：

（1）运维和开发如果是 Java 更熟，也更多 Java 的应用，那毫无疑问应该用 ZK；如果是搞 Go 的，那么还是 etcd 吧，毕竟有时候遇到问题还是要看源码的。

（2）在创建一百万个或更多键时，etcd可以比Zookeeper或Consul稳定地提供更好的吞吐量和延迟。此外，它实现了这一目标，只有一半的内存，显示出更高的效率。但是，还有一些改进的余地，Zookeeper设法通过etcd提供更好的最小延迟，代价是不可预测的平均延迟。

（3）

一致性协议： etcd 使用 Raft 协议，Zookeeper 使用 ZAB（类PAXOS协议），前者容易理解，方便工程实现；

运维方面：etcd 方便运维，Zookeeper 难以运维；

数据存储：etcd 多版本并发控制（MVCC）数据模型 ， 支持查询先前版本的键值对

项目活跃度：etcd 社区与开发活跃，Zookeeper 感觉已经快死了；

API：etcd 提供 HTTP+JSON, gRPC 接口，跨平台跨语言，Zookeeper 需要使用其客户端；

访问安全方面：etcd 支持 HTTPS 访问，Zookeeper 在这方面缺失；

与 Eureka 有所不同，Apache Zookeeper 在设计时就紧遵CP原则，即任何时候对 Zookeeper 的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是 Zookeeper 不能保证每次服务请求都是可达的。

从 Zookeeper 的实际应用情况来看，在使用 Zookeeper 获取服务列表时，如果此时的 Zookeeper 集群中的 Leader 宕机了，该集群就要进行 Leader 的选举，又或者 Zookeeper 集群中半数以上服务器节点不可用（例如有三个节点，如果节点一检测到节点三挂了 ，节点二也检测到节点三挂了，那这个节点才算是真的挂了），那么将无法处理该请求。所以说，Zookeeper 不能保证服务可用性。

当然，在大多数分布式环境中，尤其是涉及到数据存储的场景，数据一致性应该是首先被保证的，这也是 Zookeeper 设计紧遵CP原则的另一个原因。

但是对于服务发现来说，情况就不太一样了，针对同一个服务，即使注册中心的不同节点保存的服务提供者信息不尽相同，也并不会造成灾难性的后果。

因为对于服务消费者来说，能消费才是最重要的，消费者虽然拿到可能不正确的服务实例信息后尝试消费一下，也要胜过因为无法获取实例信息而不去消费，导致系统异常要好（淘宝的双十一，京东的618就是紧遵AP的最好参照）。

当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30~120s，而且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。

在云部署环境下， 因为网络问题使得zk集群失去master节点是大概率事件，虽然服务能最终恢复，但是漫长的选举事件导致注册长期不可用是不能容忍的。

Spring Cloud Netflix 在设计 Eureka 时就紧遵AP原则。Eureka是在Java语言上，基于Restful Api开发的服务注册与发现组件，由Netflix开源。遗憾的是，目前Eureka仅开源到1.X版本，2.X版本已经宣布闭源。

Eureka Server 也可以运行多个实例来构建集群，解决单点问题，但不同于 ZooKeeper 的选举 leader 的过程，Eureka Server 采用的是Peer to Peer 对等通信。这是一种去中心化的架构，无 master/slave 之分，每一个 Peer 都是对等的。在这种架构风格中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。每个节点都可被视为其他节点的副本。

在集群环境中如果某台 Eureka Server 宕机，Eureka Client 的请求会自动切换到新的 Eureka Server 节点上，当宕机的服务器重新恢复后，Eureka 会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时，所有的 *** 作都会在节点间进行复制（replicate To Peer） *** 作，将请求复制到该 Eureka Server 当前所知的其它所有节点中。

当一个新的 Eureka Server 节点启动后，会首先尝试从邻近节点获取所有注册列表信息，并完成初始化。Eureka Server 通过 getEurekaServiceUrls() 方法获取所有的节点，并且会通过心跳契约的方式定期更新。

默认情况下，如果 Eureka Server 在一定时间内没有接收到某个服务实例的心跳（默认周期为30秒），Eureka Server 将会注销该实例（默认为90秒， eureka.instance.lease-expiration-duration-in-seconds 进行自定义配置）。

当 Eureka Server 节点在短时间内丢失过多的心跳时，那么这个节点就会进入自我保护模式。

Eureka的集群中，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

Eureka不再从注册表中移除因为长时间没有收到心跳而过期的服务；

Eureka仍然能够接受新服务注册和查询请求，但是不会被同步到其它节点上（即保证当前节点依然可用）；

当网络稳定时，当前实例新注册的信息会被同步到其它节点中；

因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使得整个注册服务瘫痪。

Consul 是 HashiCorp 公司推出的开源工具，用于实现分布式系统的服务发现与配置。Consul 使用 Go 语言编写，因此具有天然可移植性（支持Linux、windows和Mac OS X）。

Consul采用主从模式的设计，使得集群的数量可以大规模扩展，集群间通过RPC的方式调用(HTTP和DNS)。

Consul 内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，不再需要依赖其他工具（比如 ZooKeeper 等），使用起来也较为简单。

Consul 遵循CAP原理中的CP原则，保证了强一致性和分区容错性，且使用的是Raft算法，比zookeeper使用的Paxos算法更加简单。虽然保证了强一致性，但是可用性就相应下降了，例如服务注册的时间会稍长一些，因为 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功 ；在leader挂掉了之后，重新选举出leader之前会导致Consul 服务不可用。

默认依赖于SDK

Consul本质上属于应用外的注册方式，但可以通过SDK简化注册流程。而服务发现恰好相反，默认依赖于SDK，但可以通过Consul Template（下文会提到）去除SDK依赖。

Consul Template

Consul，默认服务调用者需要依赖Consul SDK来发现服务，这就无法保证对应用的零侵入性。

所幸通过 Consul Template ，可以定时从Consul集群获取最新的服务提供者列表并刷新LB配置（比如nginx的upstream），这样对于服务调用者而言，只需要配置一个统一的服务调用地址即可。

Consul强一致性(C)带来的是：

Eureka保证高可用(A)和最终一致性：

其他方面，eureka就是个servlet程序，跑在servlet容器中Consul则是go编写而成。

etcd是一个采用http协议的分布式键值对存储系统，因其易用，简单。很多系统都采用或支持etcd作为服务发现的一部分，比如kubernetes。但正事因为其只是一个存储系统，如果想要提供完整的服务发现功能，必须搭配一些第三方的工具。

比如配合etcd、Registrator、confd组合，就能搭建一个非常简单而强大的服务发现框架。但这种搭建 *** 作就稍微麻烦了点，尤其是相对consul来说。所以etcd大部分场景都是被用来做kv存储，比如kubernetes。

etcd 比较多的应用场景是用于服务发现，服务发现 (Service Discovery) 要解决的是分布式系统中最常见的问题之一，即在同一个分布式集群中的进程或服务如何才能找到对方并建立连接。和 Zookeeper 类似，etcd 有很多使用场景，包括：

配置管理

服务注册发现

选主

应用调度

分布式队列

分布式锁

按照官网给出的数据， 在 2CPU，1.8G 内存，SSD 磁盘这样的配置下，单节点的写性能可以达到 16K QPS, 而先写后读也能达到12K QPS。这个性能还是相当可观。

etcd 提供了 etcdctl 命令行工具 和 HTTP API 两种交互方法。etcdctl命令行工具用 go 语言编写，也是对 HTTP API 的封装，日常使用起来也更容易。所以这里我们主要使用 etcdctl 命令行工具演示。

（1）注册中心ZooKeeper、Eureka、Consul 、Nacos对比

https://zhuanlan.zhihu.com/p/165217227?utm_source=wechat_session

（2）常用的服务发现对比（Consul、zookeeper、etcd、eureka）

https://blog.csdn.net/gaohe7091/article/details/101197107

1，编排和调度程序

2，持续集成/持续部署（CI/CD）

Travis CI是一个免费的开源CI项目，通过自动构建和测试代码更改来提高开发的效率。软件即服务（Saas）平台随即能够对代码更改的成功与否提供即时反馈。Travis CI还能够通过管理部署和通知来自动化项目开发的其他部分。

工具链接：https://travis-ci.org/

使用成本：免费

GitLab结合了CI，CD和代码审查来处理整个应用程序的生命周期。它与Docker Engine上的GitLab runner结合使用，以启用应用程序的自动化测试和构建。其他功能还包括活动流，IDE，问题跟踪和存储库管理。GitLab CI还有一个内置的容器注册表来扫描和存储Docker存储库。

工具链接：

https://about.gitlab.com/features/gitlab-ci-cd/

使用成本：

• 社区版：免费，无限用户

• 企业版入门：3.25 美元/用户/月

• 企业版高级版：16.59美元/用户/月

3，记录

Logspout是帮助管理在Docker容器中运行的程序生成的日志的一个很好的工具。它将容器应用程序日志路由到单个位置（例如，通过HTTP可用的JSON对象或流式端点）。Logspout也有一个可扩展的模块系统。

工具链接：

https://github.com/gliderlabs/logspout

使用成本：免费

Fluentd作为一个开源数据收集器工作 - 一个统一和记录所有其他容器日志的容器。拥有500多个插件，Fluentd连接到许多数据源和数据输出来收集事件这些被标记为在需要的地方路由它们。这种基于标签的路由可以使复杂的路由清晰地表达。

工具链接：https://www.fluentd.org/

使用成本：免费

作为Elastic Stack的一部分，Logstash与Beats，Elasticsearch和Kibana一起运行良好。它是一个开源的服务器端处理管道，可以传输和处理日志，事件或其他数据。

工具链接：

https://www.elastic.co/products/logstash

使用成本：免费

使用syslog-ng从各种来源收集日志，并在将它们路由到不同的目的地之前，几乎实时地处理它们。一个值得信赖的日志管理基础架构，syslog-ng将高性能功能与丰富的消息解析和重写选项结合在一起。

工具链接：https://syslog-ng.org/

使用成本：免费（根据要求可提供syslog-ng高级版的价格）

4，服务发现

由CoreOS创建，etcd是为共享配置和服务发现而设计的高可用性键值存储。该工具提供了将数据存储在一组机器上的可靠方法。它专门为运行CoreOS的集群而构建，但etcd也可以在其他 *** 作系统（包括BSD，Linux和OS X）上运行。

工具链接：https://coreos.com/etcd/

使用成本：免费

5，构建

Packer是一个Hashicorp工具，用于构建机器映像（包括Docker），并与诸如Ansible，Chef和Puppet等配置管理工具集成。它是一个轻量级的工具，可以在单个源配置的每个主要 *** 作系统上运行。

工具链接：https://www.packer.io/docs/builders/docker.html

使用成本：免费

自动Dockerize与Whales你的应用程序。唯一需要的是在主机上安装并运行Docker。然后，Whales通过输出必要的文件来运行Docker和应用程序。

使用成本：免费

Gradle插件使得所有的构建脚本都可以与Docker守护进程交互。每个任务委托给Docker-client，然后通过HTTP连接到Docker的远程API。大多数配置参数是可选的。

使用成本：免费

6，管理

这就是完整的清单！希望对你们能够有所帮助！

来自公众号：云平台从0到1

---