游客gba6jdyehhlh6_个人页

在流式布局的架构设计过程中，面对实际的业务场景，通过以下几个方面解决端到端的流式页面容器设计： 在搭建平台侧，实现页面搭建、组件管理、协议编排等能力，与投放平台、A/B实验平台和监控平台打通； 在客户端侧，采用MVVM模型，设计通用的事件协议，抽象通用的页面布局、数据管理及事件处理的能力，减少重复的代码开发，提升研发效率。在页面布局管理方面，与列表容器PowerScrollView深度结合，实现高效的页面渲染、数据驱动的页面刷新能力； 使用阿里巴巴集团 DinamicX作为DSL实现动态模板渲染，满足投放以及运营需求； 在与服务端通信协议方面，闲鱼一直在实践Flutter+FaaS的云端一体化开发，借助FaaS的能力，定义一套云端一体化的事件协议，解决业务逻辑动态化的问题，减少发版依赖，进而提升交付效率。

安装iis ，在IIS主页管理右键，获取新的平台组件，下载安装Web平台安装程序，安装以下两个插件，安装完成后重新启动IIS 2.配置Server Frams 新增一个网站：TS_WEB_80,在Server Farms 中Create Server Farm :TS_WEB_80,在TS_WEB_80添加Add Server:在添加之前我在本地计算机上安装了三台虚拟机进行测试。 3.我在101，102，129 分别存放不同的index.html进行测试，对101，102，129的index.html内容进行修改，便于区别 可以看到请求分别到达了三台服务上，简单实现了IIS Server Farms负载均衡。但是在实际中还有更多的问题需要解决：1.比如实现Session共享机制 ；2.当负载均衡服务器挂掉了怎么处理 ；3.解决了应用负载均衡，如何减少数据库的压力，进行数据库负载均衡,加入缓存机制等等，跟根据项目业务场景，如何合理的构建负载均衡解决方案，还需要不断的尝试和学习！ 博客内容仅代表个人观点,如发现阐述有误,麻烦指正,谢谢！

数据库即服务』其实可以认为是PaaS的一种变种，主要关注点在数据库上，客户不再需要去自己部署数据库，而是只需要按需使用由服务提供商提供的数据库即可，数据库的维护都交给服务提供商来完成，这样客户只需关注应用本身即可。 _MongoDB_008_jpeg 我们来具体看一下使用『数据库即服务』和原来有什么不同，这里除了列举传统全部DIY的方式之外，还对比了一种利用IaaS来自建数据库的方式，这也是现在比较常见的一种做法。我们看到传统方式，需要做很多事情，这当中还需要涉及多个团队来协作，非常不容易。然后看看第二种方式，利用IaaS来自建，这里以阿里云的云服务器ECS为例，这种方式和刚刚相比，省了不少事，但是仍然是比较麻烦的，也可能还需要涉及跨团队协作。我们再来看看如果是使用『数据库即服务』呢？只需要点下页面上的部署按钮，就可以等着用了，已经进化为完全自助服务了。从时间上来看，第一种方式可能需要花费数月，第二种可能需要花费数天，第三种则只需要数小时即可。可见『数据库即服务』的优势还是很明显的。 _MongoDB_009_jpeg 所以说为什么要『即服务』，其实是一个进化的趋势。我们经常说人不能太懒，但是懒这个字用在程序猿身上可能并不是不好的东西，因为懒，促使我们会去自动化。最早我们通过人肉操作，下载软件，编译部署，然后配置。有一天我们发现经常需要这么干很累很浪费时间，就开始写脚本来完成这些操作，生产力开始提高。等到规模更大的时候，比如要同时管理数十台数百台机器，这时候可能分发脚本也嫌麻烦了，开始写一些自动化的工具来做这个事情。到最高级阶段，就是完全实现自助服务，这是懒的最高境界。 _MongoDB_010_jpeg MongoDB简介 说完了『即服务』以及其重要性，接下来我们看一下今天的另一个主角：MongoDB，因为有些同学可能对这个不了解，所以还是简单介绍一下。 _MongoDB_011_jpeg 首先，MongoDB是什么呢，它是一个Document Store，文档型数据库，也是我们经常说的NoSQL。根据DB-Engines的数据库排名，MongoDB长期霸占着NoSQL老大的地位，现在是数据库界一位重量级选手。 _MongoDB_012_jpeg 事实上，MongoDB可以称为是一种NewSQL，它融合了传统关系型数据库和NoSQL的一些优点。最左边的3个能力是来自于关系型数据库。首先，它具备丰富的查询语句和二级索引。通过这点，用户可以以足够复杂的方式来访问和组织数据。第二点，强一致性。MongoDB支持一个灵活的一致性模型。你可以选择使用强一致性，或最终一致性，取决于你的业务场景。第三点，MongoDB能很好的集成到多企业现有技术架构中。右边3个能力 来自NoSQL，首先是灵活的数据模型，MongoDB的文档模型允许动态修改schema，不用担心有任何的性能影响。其次是高性能和高可扩展性，MongoDB可以轻松进行水平扩展，从而带来更高的吞吐和更低的延迟。最后，是全球部署，也就是高可用。接下来我们就来具体讲下MongoDB的几个关键特性。 _MongoDB_013_jpeg MongoDB的关键特性主要是3个，第一个就是灵活动态的文档模型，第二个是高可用副本集，第三个是MongoDB的水平扩展，也就是sharding。 _MongoDB_014_jpeg MongoDB以一种叫做BSON（二进制JSON）的存储形式将数据作为文档存储。具有相似结构的文档通常被组织成集合。可以把集合看成类似于关系数据库中的的表：文档对应的是行，字段对应的是列。 MongoDB将一条记录的所有数据聚合在一个文档中，而在关系数据库中则倾向于将数据分布在多个表中。这样做有几个好处，一是由于数据聚集，减少了多表JOIN的需求，这样只需要读一次就可以读到所有数据，在性能上会有很大优势。 另外，这种模型更加接近我们平时编程语言中的对象结构，可以方便开发者进行数据映射。 最后就是这种模型是schema-less的，也就是在MongoDB中不需要像关系数据库一样去事先定义每个表的schema。MongoDB一个集合内的文档之间可以拥有不同的结构，可以轻松为一个新的文档添加和减少字段，不会有任何的性能影响。这个特性非常适合开发一些新产品，可以快速迭代。 当然，过于灵活就可能导致混乱。有时候我们想要求文档必须要有某些字段，某些字段必须要有固定的类型。为此，MongoDB提供了一个文档验证功能来对文档的格式进行约束。 _MongoDB_015_jpeg 接下来说MongoDB的第二个关键特性，高可用副本集（也可以翻译成复制集）。 Mongodb副本集由一组Mongod实例（进程）组成，包含一个Primary节点和多个Secondary节点，Mongodb Driver（客户端）的所有数据都写入Primary，Secondary从Primary同步写入的数据，以保持副本集内所有成员存储相同的数据集，提供数据的高可用。 上图是一个典型的Mongdb副本集，包含一个Primary节点和2个Secondary节点。 副本集通过replSetInitiate命令（或mongo shell的rs.initiate()）进行初始化，初始化后各个成员间开始发送心跳消息，并发起Primary选举操作，获得『大多数』成员投票支持的节点，会成为Primary，其余节点成为Secondary。 这里『大多数』的定义是副本集内可投票成员的一半以上，当副本集内存活成员数量不足大多数时，整个副本集将无法选举出Primary，此时副本集将无法提供写服务，处于只读状态。通常建议将副本集成员数量设置为奇数，因为偶数个节点能容忍的节点失效和比他少1个节点的奇数个节点是一样的，但是可以节省一个节点的数据存储成本。 除了初始化的时候会进行选举，MongoDB副本集的高可用服务体现在，当副本集中没有Primary节点时，选举都会进行。比如当Primary节点宕机时，剩下的Secondary节点中会选举出新的Primary（只需要满足大多数成员存活的条件）。选举使用的算法是基于Raft协议，但是可以通过为节点配置选举优先级对选举结果进行控制。 此外需要提一下，有一些比较常见的特殊的Secondary。一个是Hidden，Hidden节点和普通的Secondary的区别是它是对Driver隐藏的节点，也就是客户端无法访问到Hidden，另外就是它的选举优先级是0，也就是它不能被选举为Primary。Hidden节点上拥有数据，因此通常会用来作一些运维任务，如数据备份、计算分析等。 另外还有一个是Arbiter，Arbiter是只参与投票，但是不存储数据的节点，这可以用在对可用性有要求，又要严格控制成本的场景。 此外还有如Priority0节点、Delayed节点等。 _MongoDB_016_jpeg MongoDB提供了一种水平扩展的方式，叫做sharding，通过这种方式对数据库进行扩容，对应用是透明的。通过sharding，可以将一个集合的数据散到多个shard节点上。这里每个shard都可以是一组副本集。应用程序通过一个路由节点（mongos）来访问sharding集群的数据。有了sharding，mongodb就可以突破单机的限制，比如磁盘、内存和IOPS等，从而提供更强大的服务能力。 _MongoDB_017_jpeg Sharded cluster由Shard、Mongos和Config server 3个组件构成。Mongos本身并不持久化数据，Sharded cluster所有的元数据都会存储到Config Server，而用户的数据则会分散存储到各个shard。Mongos启动后，会从config server加载元数据，开始提供服务，将用户的请求正确路由到对应的Shard。 Sharded cluster支持将单个集合的数据分散存储在多个shard上，用户可以指定根据集合内文档的某个字段即shard key来分布数据，目前主要支持2种数据分布的策略，范围分片（Range based sharding）或hash分片（Hash based sharding）。 范围分片下，文档是根据其shard key的值进行分片。shard key的值相邻近的文档比较有可能会被放在同一个shard上，这种方式适用于需要使用范围查询的业务。 哈希分片下，文档根据其shard key的hash值进行分片。这会保证数据分布比较均匀，但是不利于范围查询。 随着数据量的增多，MongoDB也会自动在后台对数据以chunk为单位进行负载均衡。 _MongoDB_018_jpeg 如何搭建一个MongoDB『数据库即服务』 接下来介绍一下今天的重点内容，如何搭建一个MongoDB数据库即服务。 _MongoDB_019_jpeg 首先，在我看来，数据库即服务，应该具备这些特性：自动化、按需服务、弹性、安全、高可用和可量化。第一个，自动化，这是非常关键的，是实现自助服务的基础，所有可以被自动化操作的流程都应该被自动化，不需要人工干预。第二个，按需服务，数据库即服务应该是由用户驱动的，后台应该要有一个工作流的机制来对需求进行响应。第三个，弹性，可以按需动态扩缩容。第四个，安全，这是毋庸置疑的。第五个，高可用，宕机自动切换。第六个，可量化，服务的使用量可以被衡量、报告并且是可控的。 _MongoDB_020_jpeg 此图为数据库即服务应具备的功能大图。主要包括生命周期管理、容灾体系、监控报警、数据管理和增值服务。生命周期管理包括数据库实例的新建、释放、扩缩容等，这是数据库即服务最基础的功能。容灾体系包括高可用、备份恢复，甚至更高级的如异地容灾/多活等等。监控报警一方面就是服务使用量的监控，另一方面则是报警，包括服务不可用的报警，以及一些监控数据异常的报警。数据管理指的就是可以方便的对数据进行管理，如可以提供一些图形化界面等。增值服务包括审计、诊断服务等。其中审计是数据库的一个非常重要的功能，一方面可以帮助查证问题，另一方面可以为一些数据分析或诊断提供数据源。诊断服务一方面跟踪服务的资源使用量，为是否需要扩缩容提供决策依据，另一方面主要为慢查询提供优化建议。 _MongoDB_021_jpeg 数据库即服务的核心架构就是工作流引擎，这是实现自动化及按需服务的基础。 _MongoDB_022_jpeg 生命周期管理功能包括数据库实例的新建、释放、扩缩容以及迁移。新建一个数据库实例包括分配资源（主要是主机资源）、安装数据库、初始化配置。对MongoDB来说，副本集涉及多个节点，涉及到资源的分配策略，Sharding更多。另外副本集还需要一些初始化工作，sharding需要有一个各组件的组合。释放实例比较简单，主要是资源的回收。扩缩容可以分为本地和跨机的扩缩容，其实跨机的扩缩容就是迁移。对于MongoDB来说，迁移可以直接利用MongoDB的添加节点自动同步的特性，还是比较方便的。 _MongoDB_023_jpeg 生命周期管理功能主要涉及这几个组件，包括资源管理、规格及配置管理、软件栈管理和负载均衡。资源管理主要是指主机资源的管理，这里主机可以是物理机，也可以是虚拟机，如云主机等。资源管理主要负责资源的分配和回收，此外还包括如何实施资源隔离。规格及配置管理一个是需要为数据库实例制定一些规格，以方便扩容和缩容，另一方面是负责数据库相关配置的维护。软件栈管理则包括数据库软件以及其依赖的软件的安装维护等，包括操作系统。除了这些，还需要一个负载均衡组件来保证数据库实例在资源上的分布的均衡，当有主机资源需要下线的时候，能够做到自动对其上的数据库实例进行迁移。 _MongoDB_024_jpeg 对于MongoDB来说，在实施资源分配策略时需要注意的一点是需要保证不要破坏副本集原本的高可用特性。虽然MongoDB副本集自带了高可用，但是如果你把副本集的所有节点都分布在一台物理机上，那如果这个物理机挂了，整个副本集都没用了。所以一个起码的原则是要保证MongoDB多副本的主机安全性，尽可能够做到机架安全。 _MongoDB_025_jpeg 现在我们的MongoDB数据库即服务的架构可以稍微扩充一下了，多了资源服务、规格及配置服务、软件栈服务以及负载均衡服务这几个组件。 _MongoDB_026_jpeg 接下来看一下容灾体系，这包括高可用、备份/恢复、异地容灾/多活。高可用需要有一个负责健康检查的巡检服务，另外还需要有一个容灾切换的组件。备份/恢复也是容灾体系非常重要的一环，这里有一个很容易被忽视的事情是需要做备份的有效性验证。如果备份不是有效的，那等于没有备份。异地容灾/多活是比较高级的容灾能力，实施起来比较复杂，有兴趣的同学可以参考我之前做过的一个分享 MongoDB异地容灾多活实践 _MongoDB_027_jpeg MongoDB副本集自带了高可用，我们还需要做什么工作呢？主要是需要保证容灾切换的一个可控。以一个经典的3节点P/S/H副本集为例，一方面我们可以通过配置选举优先级的方式来保持Primary和Secondary的角色稳定性。另一方面，我们希望在任意时刻，用户都可以有两个节点是可访问的，因此我们需要对节点宕机后的副本集做一些reconfig操作，保证宕机节点最终都会变成Hidden，然后统一对Hidden进行处理，比如重搭等。 _MongoDB_028_jpeg 容灾体系第二个比较重要的点就是备份恢复。备份主要需要做的是需要提供自动/手动的备份方式以及支持一些灵活的备份策略制定，如备份周期/备份保留时间等。恢复主要是看对恢复的形态做成什么样，是覆盖原来的实例还是克隆出一个新的实例来，还有就是恢复的粒度，这取决于备份能力，是只能恢复到某个全量备份，还是可以恢复到任意时间点。关于备份存储，我们要求的最要 能力是高可靠性。另外就是刚刚提过的备份有效性验证，不能等到火烧眉毛了才发现备份不可用，需要防范于未然。 _MongoDB_029_jpeg ​​关于MongoDB的备份方法，相关的文档和分享已经有很多了，这里再简单提一下。全量备份从实施方式上可以分为两种，逻辑备份和物理备份。其中逻辑备份主要使用官方提供的mongodump/mongorestore工具。物理备份则可以在文件系统或是更底层的逻辑卷、块设备这层去做。 _MongoDB_030_jpeg 从各个指标上对比逻辑备份和物理备份，在备份和恢复效率上，物理备份的优势比较明显，不过逻辑备份在兼容性上会比较好。 _MongoDB_031_jpeg MongoDB的增量备份主要通过持续的抓取oplog来实现。有了全量备份加增量备份，就可以实现恢复到任意时间点。 _MongoDB_032_jpeg 至此，我们的MongoDB数据库即服务的架构又可以得到一个比较大的扩充，主要增加了高可用以及备份相关的一些服务。 _MongoDB_033_jpeg 接下来看下数据库的监控报警，性能监控​主要涉及性能数据的采集、存储和展示。采集粒度越细越好，最好能做到秒级。报警则可以分为可用性的报警和性能数据的报警。 _MongoDB_034_jpeg 具备监控报警能力后的架构图已经有点满了，这里报警服务可以通过巡检服务和性能数据存储收集相关数据。 _MongoDB_035_jpeg 来看最后一个增值服务，一个是审计，主要涉及审计日志的采集、存储和分析。另一个是诊断服务，一个是资源使用量上的诊断，另外一个是慢查询的诊断，可以做一些索引推荐等。 _MongoDB_036_jpeg 这就是我们的MongoDB数据库即服务的完整架构，可以看到组件还是比较多的，做一个数据库即服务还不是那么容易哈。 _MongoDB_037_jpeg ​​​​​​最后做一下总结，我认为数据库即服务的核心特性有两点，一个是资源池化，另外一个是服务可量化。资源池化后才可以进行资源的自动管理，而我们需要的服务是要能够被量化的，并且是可控的。现在回顾一下之前的一键安装数据库，其实背后有许多工作要做。这里顺便做下广告，如果觉得自己搭建一个数据库即服务太麻烦，可以考虑使用现成的云服务，比如阿里云MongoDB数据库服务：）你想要的全都有！

第一阶段 虚拟机管理学习 1 了解虚拟化的历史及概念，Xen VMWare HyperV KVM特性了解； 2 分别通过virt-manager及virt-install创建一台虚拟机； 3 了解libvirt xml文件，尤其是CPU 内存 网络 磁盘 VNC的相关参数； 1） 知道如何修改CPU数量及对CPU资源做限制； 2） 知道如何修改内存大小及对内存资源做限制； 3） 知道如何添加硬盘，如何在线的attach磁盘； 4） 知道如何添加网卡，如何在线的attach网卡； 5） 知道如何修改VNC连接参数，如何在线的修改vnc密码； 4 能通过virsh virt-manager完成虚拟机创建、维护、销毁的生命周期管理； 5 学习qemu-img 命令； 6 学习virt-resize virt-inspector virt-inspector2等虚拟机镜像管理命令； 7 学习guestfish guestmount虚拟机镜像挂载命令； 第二阶段 虚拟机CPU内存优化及多宿主机管理 CPU优化：NUMA特性及虚拟机绑定特定CPU配置； 内存优化：内存压缩、大页内存概念及配置； 宿主机之间通过tcp方式连接练习及测试； 宿主机之间通过tls方式连接练习及测试（重点）； 通过远程方式，利用virsh命令创建linux虚拟机一台； 通过远程方式，利用virt-manager创建windows虚拟机一台； 第三阶段 虚拟化网络管理 1 linux 网桥、子接口、VLAN创建学习； 2 多网卡绑定学习； 3 libvirt virsh网络管理相关命令学习：如何定义、删除、修改网络配置 4 全虚拟化网卡和半虚拟化网卡在理论上的区别； 5 网络性能测试工具netperf学习及联系； 6 网卡SRIOV pci passthrough 原理学习、实际环境联系及提交性能测试报告； 第四阶段 虚拟化存储管理 了解qcow2 raw 格式区别及创建方法； 学习lvm管理：创建pv vg lv 并扩展lv，将lv挂载给虚拟机使用； 学习fio iozone磁盘压力测试工具，并提交qcow2 raw lv方式性能对比测试报告； 学习ide全虚拟化方式和virtio半虚拟化方式概念，并提交两种方式性能对比测试报告； 了解libvirt 存储池的概念，并能通过virsh xml文件对libvirt存储池进行管理； 搭建基于系统的nfs存储，挂载给多宿主机，并实现在线虚拟机迁移； 搭建基于系统的ISCSI存储，挂载给多宿主机，并实现在线虚拟机迁移； 搭建DRBD系统，以 ISCSI方式挂载给多宿主机，并实现在线虚拟机迁移； 搭建glusterFS系统，挂载给多宿主机，并实现在线虚拟机迁移； 搭建ceph系统，挂载给多宿主机，并实现在线虚拟机迁移； 搭建sheedog系统，挂载给多宿主机，并实现在线虚拟机迁移（选修）； SSD性能测试，配置flashcache，划分lv给虚拟机使用，并提交性能测试报告； centos7 lvm cache配置，给虚拟机使用，并提交性能测试报告； 第五阶段 虚拟化平台管理 1 virt-manager管理多宿主机练习； 2 opennebula管理平台搭建； 3 cloudstack管理平台搭建； 4 openstack管理平台搭建； 5 convirture VMWare vcenter Xen Server 微软SCVMM管理平台概念了解； 6 提交各个管理平台对比文档，包括以下内容对比： 1） 镜像管理； 2） 网络管理； 3） 存储管理； 4） 节点（宿主机）管理； 5） 虚拟机管理； 6） API； 第六阶段 虚拟化监控、报警及应急响应 1 了解linux性能查看常用工具，练习写一个小脚本，实现当网卡流量超过10M发邮件报警； 2 了解windows系统性能查看方法； 3 学习hpacucli MagaCli命令，能够查看服务器RAID卡状态及磁盘健康状态； 4 cacti搭建并实现宿主机监控，设置超过阀值会报警，宿主机没有响应会报警； 5 zabbix搭建并实现宿主机监控，设置超过阀值会报警，宿主机没有响应会报警； 6 划分故障等级，制订应急预案： 1） 一台虚拟机故障如何快速发现并处理； 2） 宿主机硬盘故障如何快速发现并处理； 3） 宿主机风扇、电源故障如何快速发现并处理； 4） 宿主机彻底故障，数据无法恢复如何快速发现并处理； 5） 网络出现故障如何快速发现并处理； 第七阶段 和业务融合 1 了解自己的业务并划出相关业务流程图； 2 了解自己业务的压力情况，并根据压力情况提炼出压力模型； 3 测试环境测试，取得相关数据进行稳定性及性能验证； 4 小范围部署，观察稳定性和性能数据； 5 扩展部署范围，和各个接口明确责任和流程，定期进行预警演练； 6 阶段性进行总结，并提交报告； http://koumm.blog.51cto.com/703525/1590279

大型动态应用系统平台主要是针对于大流量、高并发网站建立的底层系统架构。大型网站的运行需要一个可靠、安全、可扩展、易维护的应用系统平台做为支撑，以保证网站应用的平稳运行。　 　　大型动态应用系统又可分为几个子系统： Web前端系统 负载均衡系统 数据库集群系统 缓存系统 分布式存储系统 分布式服务器管理系统 代码分发系统 　　Web前端系统 　　为了达到不同应用的服务器共享、避免单点故障、集中管理、统一配置等目的，不以应用划分服 务器，而是将所有服务器做统一使用，每台服务器都可以对多个应用提供服务，当某些应用访问量升高时，通过增加服务器节点达到整个服务器集群的性能提高，同时使他应用也会受益。 　　该Web前端系统基于IIS/ASP.NET等的虚拟主机平台，提供PHP程序运行环境。服务器对开发人员是透明的，不需要开发人员介入服务器管理。 　　负载均衡系统 　　负载均衡系统分为硬件和软件两种。硬件负载均衡效率高，但是价格贵，比如F5等。软件负载均衡系统价格较低或者免费，效率较硬件负载均衡系统低，不过对于流量一般或稍大些网站来讲也足够使用，比如lvs,nginx。大多数网站都是硬件、软件负载均衡系统并用。

随着Internet的迅速发展，基于Web的信息交流、共享与协作成为企业的重要发展方向。企业的大量重要的信息都是通过数据库系统进行存储和管理的，而不同的企业或者同一企业的不同部门往往采用了不同的数据库管理系统,如Oracle、DB2、Informix、Sybase、MS SQL Server等，而且这些不同的数据库管理系统在地理位置上往往也是分布的，只能通过Internet访问。例如某公司在北京，上海，南京，武汉等地都有分公司，甚至在国外也有分公司。各分公司可能安装了不同的数据库管理系统。即使该公司进行了信息系统规划，但是，随着时间的推移，人事的变动以及数据库技术的进步和数据库市场的变化，仍然可能出现分布的异构数据库的情况。该公司的管理者对下级各分公司，各部门要进行统一协调的管理，调度，以降低成本

服务这个词，对于任何人来说都不陌生，那么什么是服务呢？在现实世界中，服务可以理解为做一些事情，比如说去饭店吃饭，服务人员的服务就是给你那菜单，帮你上菜等，其实这就是一种功能。在编程的世界里，服务是暴露在外的一组功能的集合。在WCF中，经常会看到ABC这三个词，其实WCF框架的核心是ABC，其他的配置，接口，属性，工具，模板等都是围绕ABC在展开。 A:Address Where B:Binding How C:Contract What WCF的全称是：Windows Communication Foundation。从本质上来说，它是一套软件开发包，是微软公司推出的符合SOA思想的技术框架。 WCF为程序员提供了丰富的功能，其中包括：托管、服务实例管理、异步、安全、事务管理、离线队列等。并且WCF对产业中的标准协议进行了封装和定义，它把程序员从繁琐的通信、格式编码中解放出来，使得程序员能够专注于业务逻辑的实现。同时，WCF统一了微软公司之前推出的多种分布式技术，其中包括： Web服务和WSE。 .Net Remoting。 .Net 企业服务。 微软消息队列（MSMQ）。 WCF对这些技术的集成包括两个方面： WCF的架构本身吸取了这些技术的精华。 WCF开发的服务/客户端可以和现有的Web服务、MSMQ程序进行交互。 .Net Framework的四大体系架构 .Net Framework的四大体系包括：WCF、WF、WPF、WCS。 WCF（Windows Communication Foundation）：主要是用来做松耦合的分布式通讯的，它还有另外一个名字叫Indigo，是微软迈向SOA一个重要的标志。WCF是.Net Framework的一个子集。 WF（Windows Wordflow Foundation）：工作流引擎。 WPF（Windows Presenttation Foundation）：WPF使用矢量绘图引擎，提供了一种声明式编程语言XAML，用来开发具有炫目视觉效果的应用程序。 WCS（Windows Card Space）：采用了一种新的数字标识技术来实现类似网银单点登录的功能，主要用来防止钓鱼式攻击等，从网络安全方面提供了一个保障。 WCF体系框架 clip_image001 从图上来看，WCF的体系基本包含了4个方面，分别为契约、服务运行时、消息和寄宿。 1 契约（能干什么） 从SOA的概念上来看，契约属于一个服务公开接口的一部分。一个服务的契约，定义了服务端公开的服务方法、使用的传输协议、可访问的地址、传输的消息格式等内容。 基本上，契约的定义描述了该服务的功能和作用，它告诉SOA系统中的其它节点这个服务是“干什么”的。 2 服务运行时（怎么干） 服务运行时定义了服务在运行时的具体行为。如果说契约描述了服务是“干什么”的，那么服务运行时就在一定程度上描述了服务是“怎么干”的。 3 消息 消息方面包含了消息的传输方式、消息的编码与解码。消息方面的内容基本属于服务边界以内的具体实现。具体的传递时限，必须符合在契约中定义的绑定协议。 4 激活和宿主（在哪干） 激活和宿主属于WCF程序的部署方式。一个WCF服务需要在一个可运行的程序中寄宿，我们可以把宿主理解为WCF运行的容器。常用的寄宿方式包括自寄宿、IIS寄宿、Windows激活服务、Windows服务、Com+组件等。根据SOA的原则，激活和宿主类型的变化不会影响服务本身的特性和外部对该服务的访问，而WCF在这一方面也确实做的非常出色。

在之前，每一个新的分布式系统，例如 Hadoop 和 Cassandra ，都需要构建自己的底层架构，包括消息处理、存储、网络、容错性和可伸缩性。庆幸的是，像 Apache Mesos 这样的系统，通过给分布式系统的关键构建模块提供类似操作系统的管理服务，简化了构建和管理分布式系统的任务。Mesos 抽离了 CPU 、存储和其它计算资源，因此开发者开发分布式应用程序时能够将整个数据中心集群当做一台巨型机对待。 构建在 Mesos 上的应用程序被称为框架，它们能解决很多问题： Apache Spark，一种流行的集群式数据分析工具；Chronos ，一个类似 cron 的具有容错性的分布式 scheduler ，这是两个构建在 Mesos 上的框架的例子。构建框架可以使用多种语言，包括 C++，Go，Python，Java，Haskell 和 Scala。 在分布式系统用例上，比特币开采就是一个很好的例子。比特币将为生成 acceptable hash 的挑战转为验证一块事务的可靠性。可能需要几十年，单台笔记本电脑挖一块可能需要花费超过 150 年。结果是，有许多的“采矿池”允许采矿者将他们的计算资源联合起来以加快挖矿速度。Mesosphere 的一个实习生， Derek ，写了一个比特币开采框架（https://github.com/derekchiang/Mesos-Bitcoin-Miner），利用集群资源的优势来做同样的事情。在接下来的内容中，会以他的代码为例。 1 个 Mesos 框架有 1 个 scheduler 和 1 个 executor 组成。scheduler 和 Mesos master 通信并决定运行什么任务，而 executor 运行在 slaves 上面，执行实际任务。大多数的框架实现了自己的 scheduler，并使用 1 个由 Mesos 提供的标准 executors 。当然，框架也可以自己定制 executor 。在这个例子中即会编写定制的 scheduler，并使用标准命令执行器（ executor ）运行包含我们比特币服务的 Docker 镜像。 对这里的 scheduler 来说，需要运行的有两种任务—— one miner server task and multiple miner worker tasks。 server 会和一个比特币采矿池通信，并给每个 worker 分配 blocks 。Worker 会努力工作，即开采比特币。

下面以某开源堡垒机搭建为例： 1、准备 Python3 和 Python 虚拟环境 ①安装依赖包 ②编译安装python3 ③建立 Python 虚拟环境 2、安装堡垒机 ①下载或 Clone 项目 ②安装依赖 RPM 包 ③安装 Python 库依赖 ④安装 Redis ⑤创建数据库 堡垒机 并授权 ⑥修改 堡垒机 配置文件 ⑦生成数据库表结构和初始化数据 ⑧运行堡垒机 3、安装 SSH Server 和 WebSocket Server: Coco ①下载或 Clone 项目 ②安装依赖 ③查看配置文件并运行 ④测试连接 4、安装 Web Terminal 前端: Luna 5、配置 Nginx 整合各组件