服务器与组织架构的关系？

我们将商品社会的基本行为抽象为服务的消费者和服务的提供者模式，在这个模式下几乎可以涵盖所有的商业行为。但是，问题来了，到底谁是服务的所有者(owner)昌平镇电脑培训发现大多数人会认为提供者是服务的所有者，所以在传统的企业中，IT应用系统对服务的生命周期负责，应用系统的产品经理来定义应用系统对外的服务接口。这带来一个问题，同样的一类应用，由于实现的厂商不一样，所以各自的产品对外提供的服务千差万别，这就造成了服务的消费系统无所适从。

于是，我怀疑服务的提供者作为服务的owner来决定服务的生命周期甚至服务的定义是否具有合理性。首先，我认为服务的消费者真正决定了服务的内涵，也就是需求决定服务，从这个意义上讲服务是消费者定义的，提供者只是根据消费者对服务的定义通过技术手段实现了服务，只是服务的外延。这样看来，消费者是服务的理论上的定义者，而提供者是服务事实上的定义者，这两者在定义权上是有冲突的。

我认为，商业社会中解决冲突的最有效方法就是订立契约。假如有一个虚拟的服务提供者从大量消费者的需求中抽象出共同的行为模式，这个行为模式因为能涵盖消费者某些消费需求，就能隐式的和消费者签订提供服务的契约了。所谓隐式意思是说，虽然没有和消费者正式的签订合约，但是服务的合约内涵已经满足甚至超过任何一个消费者对此类服务的需求。可以将这个单方面定义合约的角色称为服务产品经理，服务产品经理在一个企业中的角色更像一个真正的产品经理，他们对自己的产品(服务)负责，他们定义并描述服务在各个维度上的属性，并不断寻找合适的服务提供者提供更优质的服务水平。

我们有理由相信，在后SOA时代，随着社会分工的进一步精细化，企业内部的IT系统将逐步的减少，取而代之的是更专业化的外部专业系统。而企业内部将会出现专职的服务产品经理来定义企业所需的服务，这些服务通过灵活的接口与外部专业系统对接，从而低成本、灵活高效的为企业提供高质量的IT服务。

所谓刀片服务器是指在标准高度的机架式机箱内可插装多个卡式的服务器单元，实现高可用和高密度。每一块"刀片"实际上就是一块系统主板。它们可以通过"板载"硬盘启动自己的 *** 作系统，如Windows NT/2000、Linux等，类似于一个个独立的服务器，在这种模式下，每一块母板运行自己的系统，服务于指定的不同用户群，相互之间没有关联。不过，管理员可以使用系统软件将这些母板集合成一个服务器集群。在集群模式下，所有的母板可以连接起来提供高速的网络环境，并同时共享资源，为相同的用户群服务。在集群中插入新的
"刀片"，就可以提高整体性能。而由于每块"刀片"都是热插拔的，所以，系统可以轻松地进行替换，并且将维护时间减少到最小。
这些刀片服务器在设计之初都具有低功耗、空间小、单机售价低等特点，同时它还继承发扬了传统服务器的一些技术指标，比如把热插拔和冗余运用到刀片服务器之中，这些设计满足了密集计算环境对服务器性能的需求；有的还通过内置的负载均衡技术，有效地提高了服务器的稳定性和核心网络性能。而从外表看，与传统的机架/塔式服务器相比，刀片服务器能够最大限度地节约服务器的使用空间和费用，并为用户提供灵活、便捷的扩展升级手段。
刀片服务器的特点
刀片服务器公认的特点有两个，一是克服了芯片服务器集群的缺点，被成为集群的终结者；另一个是实现了机柜优化。
集群终结者
众所周知，作为一种负载均衡技术，服务器集群已经在有效提高系统的稳定性和核心网络服务的性能方面被广泛采用，在集群系统中，若要提供更高端的运算和服务性能，只需增加更多的单元就可以获得更高的性能。更为重要的是，服务器集群还可以为任何一台单独的服务器提供冗余和容错功能。
目前IT行业正在大力发展适应宽带网络、功能强大可靠的计算机。在过去的几年里，宽带技术极大地丰富了信息高速公路的传输内容。服务器集群和RAID技术的诞生为计算机和数据池的互联网应用提供了一个新的解决方案，而其成本却远远低于传统的高端专用服务器和大型机。但是，服务器集群的集成能力低，管理这样的集群使很多管理员非常头疼。尤其是集群扩展的需求越来越大，维护这些服务器的工作量简直不可想像，包括服务器之间的内部连接和摆放空间的要求。这些物理因素都限制了集群的扩展。刀片服务器的出现适时地解决了这些问题。在集群模式下，刀片服务器所有的主板可以连接起来提供高速的网络环境，共享资源。同时每个刀片都可内置监视器和管理工具软件， 配置一台高密度服务器就可以解决一台到一百台服务器的管理问题，如果需要增加或者删除集群中的服务器，只要插入或拔出一块板即可，将维护时间减少到最小。就这个意义上来说，Blade Server从根本上克服了服务器集群的缺点。
实现机柜优化
从某一角度而言，刀片服务器实现了机柜优化的自然飞跃。刀片服务器将机柜式服务器所占用的空间密度再一次提高了50%。资料显示，在机柜系统配置好的前提下，将1U机架优化服务器系统移植到刀片服务器上，所占用的空间只是原来的1/3～1/2。而在一个标准的机柜式环境里，刀片服务器的处理密度要提高四到五倍。比如在处理1024节点的高密度计算服务器环境里，1U配置需要24个机柜，其中不包括以太网交换集线器所占用的机柜空间，而采用插有8个"刀片"的刀片服务器，只需要9个机柜，却包括了以太网交换机的空间。在相同的面积内，数据中心可以通过部署刀片服务器获得8倍于机架式服务器的服务器租赁收益。
另外，刀片服务器采用集中管理的方式，可以简化服务器的管理工作。在IT人员日益匮乏的今天，采用刀片服务器的企业可以减少雇佣工资高昂的服务器管理和维护人员，从而降低维护费用。还有，刀片服务器的低功耗设计也会显著减少能耗，节约能源的同时减少了费用。
作为一种新兴的服务器产品，读者可能还缺乏对它的直观认识。每台刀片服务器一般由机柜和刀片组成，因此刀片服务器的标识由机柜的型号和刀片的型号共同构成，而不像以往的服务器那样由一个单一的服务器型号所代表。刀片通过机柜背板上的CompacPCI接口与之相连接。服务器机柜一般可以容纳8片至数十片刀片。刀片以服务器刀片为主，而每个服务器刀片都是一个功能完整的服务器。
在此，我们以一款常见的一种刀片服务器向大家介绍一下，以了解其基本构成。
根据所需要承担的服务器功能，刀片服务器被分成服务器刀片、网络刀片、存储刀片、管理刀片、光纤通道SAN刀片、扩展I/O刀片等等不同功能的相应刀片服务器。
目前最为常见的服务器刀片一般采用1颗为的Intel Pentium Ⅲ处理器，并采用ServerWorks LC-E芯片组、Intel 815芯片组、Via Pro266芯片组，支持的内存容量和类型由芯片组决定，内存类型一般为具有ECC功能的SDRAM或DDR。由于刀片服务器的散热问题较为严重，在设计中也有厂商采用了低功耗的Transmeta 5600处理器。目前，HP、Sun也正致力于把它们的RISC处理器制作成服务器刀片，只是尚未面世。
除连接机柜背板的接口外，服务器刀片上一般还具有一个PMC扩展接口，可以连接PMC接口的扩展卡，如SCSI卡、光纤存储卡等，其功能相当于PCI扩展槽，只是相应接口的扩展卡价格略贵。 服务器刀片采用与笔记本电脑相同规格的65mm(25英寸)硬盘，一般只安装 *** 作系统和简单的应用软件，性能较低。
网络刀片
网络刀片的功能相当于局域网交换机，从而提供良好的网络监控和管理功能。网络刀片普遍提供10/100Mbps端口，以双绞线的方式连接服务器刀片，对外提供高速上连通道(千兆端口)。采用NAS存储方式的刀片服务器经常会配备2个网络刀片，其中一个专门用于连接NAS设备。每个刀片支持10/100/1000M以太网连接，并且可以在背板上安装10/100/1000M的2-4层交换机，这样就可以把系统中每个槽位上安装的刀片与交换机连接起来，提供一个基于IP的交换网络。通过集成这种总线，刀片服务器系统可以很好地集成IP业务和语音业务，提供各种不同的电信增值服务。
存储刀片
存储刀片可以被视为一个硬盘模块，通过背板总线或者硬盘接口线向服务器刀片提供存储功能。存储刀片上一般配备2块性能较高90mm(35英寸)硬盘，接口类型有IDE、SCSI和光纤通道(Fiber Channel)接口。
管理刀片
第一代刀片服务器的KVM(Keyboard、VGA、Mouse)刀片可以说是功能最为简单的管理刀片，提供对所有服务器刀片的管理控制。KVM刀片，提供键盘、鼠标、显示器接口，KVM刀片经常还包括软驱和光驱，便于使用者直接 *** 作服务器刀片。KVM刀片上提供切换开关，用于在机柜上的不同刀片之间或者不同机柜之间进行切换。第二代刀片服务器具备更加强大的管理功能，但是各家产品各不相同。管理刀片往往通过服务器刀片上集成的监控管理芯片进行1台或多台刀片服务器的集中监控和管理。管理刀片向服务器机柜内的其他刀片提供必要的配置信息，并在某些刀片发生故障时接收报警信息，并向监控程序发出报警。
CompactPCI ：刀片服务器的标准
CompactPCI开放式标准架构很好地平衡了业界标准，包括硬件、 *** 作系统、应用开发工具、能快速有效开发高利润的电信增值服务，同时使传统上以专有软硬件架构为主的电信建设转型，能享受开放系统带来成本大幅降低及大众化业界标准 *** 作系统的好处。这一转变让设备及服务供应商找到了数以百万计的开发者，并开始采用具高可靠性、高扩展性和高性能的CompactPCI宽频通讯平台。
CompactPCI总线标准是建立刀片服务器的基础。它是惟一的标准，同时也是标准纷争的起源。CompactPCI目前有2个主要的版本，即 10版和20版，它们在接口定义的完善程度上不尽相同。早期的刀片服务器全部采用CompactPCI 10的标准，背板带宽也限定在32位PCI之内，这些产品属于第一代刀片服务器。2002年最新推出的刀片服务器部分采用CompactPCI 20标准，背板支持64位PCI通信，称之为第二代刀片服务器。由于标准的版本不同，两代刀片服务器之间不能完全兼容。
目前为止，只有HP一家声称完全按照CompactPCI标准设计刀片服务器，而其他服务器厂商只是在总线和接口标准方面遵循CompactPCI，在刀片的尺寸上没有完全按照该标准去执行。
应用模式指南
刀片服务器的应用很广泛，尤其是对于计算密集型应用，比如天气预报建模、数据采集、数据仿真、数字影象设计、空气动力学建模等等。而对于行业应用，如电信、金融、 IDC/ASP/ISP应用、移动电话基站、视频点播、Web主机 *** 作及实验室系统等，刀片服务器依然能大显身手。刀片服务器的出现使其在2001年底的服务器市场上占据一块相对于机架式服务器来说不算小的市场份额。而随着2002年技术的发展尤其是InfiniBand技术开始扮演重要角色，刀片服务器将逐渐成为主流服务器并占据较大的市场份额。
刀片服务器的使用范围相当广泛。下面我们列出两个典型的应用模式进行简单的介绍。
应用模式1：网站Web服务器
这种方式可充分发挥刀片服务器密度高、可群集以及可远程管理的优势。网站可以用刀片服务器组成高密度的群集，用来实现高访问量的Web服务器，后端再连接中高端的服务器或群集系统作为数据库服务器。存储服务提供商可以采用同样的前端方案，后端配合NAS设备来提供存储服务。与普通机架服务器相比，刀片服务器在这类应用中的优势在于占用机位少，可有效节省托管费用。
应用模式2：中小企业网络服务器
当前的企业网络需求是多方面的，需要类型多样的服务，其中有些服务可以安装在一台机器上，而有些则需要使用至少一台备份机器或者群集。与之相对应，任何一个刀片系统既可以独立运行，也可以与其他服务器组成群集或互为备份。根据企业的实际需要进行搭配。这种方式可充分发挥刀片服务器易管理、配置灵活和可扩展性好的优势。 使用刀片服务器进行群集并与存域网相结合，这可以胜任大数据量吞吐的数据库并行处理。对于企业来说，这种高密度不仅节约了宝贵的机柜空间，还节约了布线成本，并可节电，从而降低对UPS的要求。

分类: 无分类
问题描述:

这个加构是什么意思呀？

解析:

表示你采用的CPU是通常所说的PC系统的CPU，例如P4 A64或者至强、皓龙

还有其他的架构比如安腾或者RISC，其中安腾自然就是Intel的安腾了，RISC包括IBM的Power5处理器还有Sun等公司的产品

目前普遍认为x86的系统通用扩产性好，所以一般都基于这个架构
至于“架构”这个词，主要指的是CPU的指令集以及主板总线的类型。

微服务¹架构的目标是帮助工程团队更快，更安全，更高质量地交付产品。解耦服务允许团队快速迭代，对系统的其余部分影响最小。

在Medium，我们的技术堆栈始于2012年的单片Nodejs应用程序。我们已经构建了几个卫星服务，但我们还没有制定一个系统地采用微服务架构的策略。随着系统变得越来越复杂并且团队不断发展，我们在2018年初转向了微服务架构。在这篇文章中，我们希望分享我们有效地做到这一点并避免微服务综合症的经验。

首先，让我们花一点时间来思考微服务架构是什么，不是什么。 “微服务”是那些过载和混乱的软件工程趋势之一。这就是我们在Medium认为它是什么：

该定义包括三个微服务设计原则：

Three Principles of Modeling Microservices

当我们对微服务进行建模时，我们应该遵守所有三个设计原则。这是实现微服务架构全部潜力的唯一途径。错过任何一个都会成为反模式。

没有一个目的，每个微服务最终会做太多事情，成长为多个“单片”服务。我们不会从微服务架构中获得全部好处，我们也会支付运营成本。

如果没有松散耦合，对一个服务的更改会影响其他服务，因此我们无法快速安全地发布更改，这是微服务架构的核心优势。更重要的是，紧密耦合引起的问题可能是灾难性的，例如数据不一致甚至数据丢失。

如果没有高凝聚力，我们将最终得到一个分布式单片系统 - 一组混乱的服务，必须同时进行更改和部署才能构建单一功能。由于多个服务协调的复杂性和成本（有时跨多个团队），分布式单片系统通常比集中式单片系统差得多。

与此同时，了解 微服务不是什么 很重要：

在Medium，我们总是在做出重大产品或工程决策时会问“为什么现在？”这个问题。 “为什么？”是一个显而易见的问题，但它假设我们拥有无限的人，时间和资源，这是一个危险的假设。当你想到“为什么现在？”时，你突然有了更多的限制 - 对当前工作的影响，机会成本，分心的开销等等。这个问题有助于我们更好地优先考虑。

我们现在需要采用微服务的原因是我们的Nodejs单片应用程序已经成为多个方面的瓶颈。

首先，最紧迫和最重要的瓶颈是其性能。

某些计算量很大且I / O很重的任务不适合Nodejs我们一直在逐步改进整体应用程序，但事实证明它是无效的。它的低劣性能使我们无法提供更好的产品而不会使已经非常慢的应用程序变慢。

其次，整体应用程序的一个重要且有点紧迫的瓶颈是它会减慢产品开发速度。

由于所有工程师都在单个应用程序中构建功能，因此它们通常紧密耦合。我们无法灵活地改变系统的一部分，因为它也可能影响其他部分。我们也害怕做出重大改变，因为影响太大，有时难以预测。整个应用程序作为一个整体进行部署，因此如果由于一次错误提交导致部署停滞，那么所有其他更改（即使它们完全正常工作）也无法完成。相比之下，微服务架构允许团队更快地发货，学习和迭代。他们可以专注于他们正在构建的功能，这些功能与复杂系统的其余部分分离。更改可以更快地进入生产。他们可以灵活地安全地尝试重大变革。

在我们新的微服务架构中，更改会在一小时内完成生产，工程师不必担心它会如何影响系统的其他部分。该团队还 探索 了在开发中安全使用生产数据的方法²多年来一直是白日梦。随着我们的工程团队的发展，所有这些都非常重要。

第三，单一应用程序使得难以为特定任务扩展系统或隔离不同类型任务的资源问题。

使用单一的单一应用程序，我们必须扩展和缩小整个系统，以满足更多资源需求的任务，即使这意味着系统过度配置用于其他更简单的任务。为了缓解这些问题，我们对不同类型的请求进行分片，以分离Nodejs进程。它们在一定程度上起作用，但不会扩展，因为这些微单一版本的单片服务是紧密耦合的。

最后但同样重要的是，一个重要且即将成为紧迫的瓶颈是它阻止我们尝试新技术。微服务架构的一个主要优点是每个服务都可以使用不同的技术堆栈构建，并与不同的技术集成。这使我们能够选择最适合工作的工具，更重要的是，我们可以快速安全地完成工作。

采用微服务架构并非易事。它可能会出错，实际上会损害工程生产力。在本节中，我们将分享七个在采用早期阶段帮助我们的策略：

有人可能会认为采用新的服务器架构意味着产品开发的长时间停顿以及对所有内容的大量重写。这是错误的做法。我们永远不应该为了建立新的服务而建立新的服务。每次我们建立新服务或采用新技术时，都必须具有明确的产品价值和/或工程价值。

产品价值应以我们可以为用户提供的利益为代表。与在单片Nodejs应用程序中构建值相比，需要一项新服务来提供值或使其更快地交付值。工程价值应该使工程团队更好，更快。

如果构建新服务没有产品价值或工程价值，我们将其留在单一的应用程序中。如果十年内Medium仍然有一个支持某些表面的单片Nodejs应用程序，那就完全没了问题。从单一应用程序开始实际上有助于我们战略性地对微服务进行建模。

建立具有明确价值的新服务

有人可能会认为采用新的服务器架构意味着产品开发的长时间停顿以及对所有内容的大量重写。这是错误的做法。我们永远不应该为了建立新的服务而建立新的服务。每次我们建立新服务或采用新技术时，都必须具有明确的产品价值和/或工程价值。

产品价值应以我们可以为用户提供的利益为代表。与在单片Nodejs应用程序中构建值相比，需要一项新服务来提供值或使其更快地交付值。工程价值应该使工程团队更好，更快。

如果构建新服务没有产品价值或工程价值，我们将其留在单一的应用程序中。如果十年内Medium仍然有一个支持某些表面的单片Nodejs应用程序，那就完全没了问题。从单一应用程序开始实际上有助于我们战略性地对微服务进行建模。

单片持久存储被认为是有害的

建模微服务的很大一部分是对其持久数据存储（例如，数据库）进行建模。跨服务共享持久数据存储通常似乎是将微服务集成在一起的最简单方法，然而，它实际上是有害的，我们应该不惜一切代价避免它。这就是原因。

首先，持久数据存储是关于实现细节的。 跨服务共享数据存储会将一个服务的实现细节暴露给整个系统。如果该服务更改了数据的格式，或者添加了缓存层，或者切换到不同类型的数据库，则还必须相应地更改许多其他服务。 这违反了松散耦合的原则。

其次，持久数据存储不是服务行为，即如何修改，解释和使用数据 。如果我们跨服务共享数据存储，则意味着其他服务也必须复制服务行为。 这违反了高内聚的原则 - 给定域中的行为泄露给多个服务。如果我们修改一个行为，我们将不得不一起修改所有这些服务。

在微服务架构中，只有一个服务应该负责特定类型的数据。所有其他服务应该通过负责服务的API请求数据，或者保留数据的 只读非规范（可能具体化）副本 。

这可能听起来很抽象，所以这是一个具体的例子。假设我们正在构建一个新的推荐服务，它需要来自规范帖子表的一些数据，目前在AWS DynamoDB中。我们可以通过两种方式之一为新推荐服务提供发布数据。

在单片存储模型中，推荐服务可以直接访问单片应用程序所执行的相同持久存储。这是一个坏主意，因为：

缓存可能很棘手。 如果推荐服务与单一应用程序共享相同的缓存，我们也必须在推荐服务中复制缓存实现细节;如果推荐服务使用自己的缓存，当单片应用更新帖子数据时，我们将不知道何时使其缓存无效。

如果单片应用程序决定更改为使用RDS而不是DynamoDB来存储帖子数据，我们将不得不重新实现推荐服务中的逻辑以及访问帖子数据的所有其他服务。

单片应用程序具有解释帖子数据的复杂逻辑 ，例如，如何确定帖子是否应该对给定用户不可见。我们必须在推荐服务中重新实现这些逻辑。一旦整体应用程序更改或添加新逻辑，我们也需要在任何地方进行相同的更改。

即使推荐服务是自己的数据访问模式的错误选项，推荐服务仍然停留在DynamoDB上。

在解耦存储模型中，推荐服务不能直接访问发布数据，也不能直接访问任何其他新服务。发布数据的实​​现细节仅保留在一个服务中。有不同的方法来实现这一目标。

Option A 理想情况下，应该有一个拥有帖子数据的Post服务，其他服务只能通过Post服务的API访问邮政数据。但是，为所有核心数据模型构建新服务可能是一项昂贵的前期投资。

当人员配置有限时，还有一些更实用的方法。根据数据访问模式，它们实际上可能是更好的方式。

在 选项B 中，单一应用程序可让推荐服务知道何时更新相关的帖子数据。通常，这不必立即发生，因此我们可以将其卸载到排队系统。

在 选项C 中，ETL管道生成推荐服务的发布数据的只读副本，以及可能对推荐有用的其他数据。在这两个选项中，推荐服务完全拥有其数据，因此它可以灵活地缓存数据或使用最适合的数据库技术。

解耦“建立服务”和“运行服务”

如果构建微服务很难，那么运行服务往往更难。 当运行服务与构建每个服务相结合时，它会减慢工程团队的速度，团队必须不断重新发明这样做。我们希望让每项服务都专注于自己的工作而不用担心如何运行服务的复杂问题，包括网络，通信协议，部署，可观察性等。服务管理应该与每个服务的实现完全分离。

由于最近在 容器化，容器编排，服务网格，应用程序性能监 控等方面的技术进步，“运行服务”的解耦变得比以往更容易实现。

网络。 网络（例如，服务发现，路由，负载平衡，流量路由等）是运行服务的关键部分。传统方法是为每种平台/语言提供库。它工作但不理想，因为应用程序仍然需要非常繁琐的工作来集成和维护库。通常，应用程序仍然需要单独实现某些逻辑。现代解决方案是在Service Mesh中运行服务。在Medium，我们使用 Istio和Envoy作为边车代理 。构建服务的应用工程师根本不需要担心网络问题。

通信协议 。无论您选择哪种技术堆栈或语言来构建微服务，从一个高效，类型化，跨平台且需要最少开发开销的成熟RPC解决方案开始是非常重要的。支持向后兼容性的RPC解决方案也使部署服务更加安全，即使它们之间存在依赖关系。在Medium，我们选择了gRPC。

一种常见的替代方案是基于>