《GMP平台关键技术》

各位同事，大家周末好，我是售前支持部的赵彦兵。对于好多老同事，可能很熟悉了，对于部分新同事，可能要好好熟悉一下。

剧情回顾

经过两个周末的产品学习，我想大家已经对GMP清楚了，他的用武之地，他的优势、案例，销售过程话术等。    通过售前的一些数据统计，确实大家对于GMP的关注度有了很明显的提升。今天我们就想让大家更进一步，更深一层的了解、学习到之前的一些名词、原理，衍生、扩展相关知识点。

我这个人，有个毛病，就是总喜欢问问题？比如

1. Java和Javacript是什么关系？

2. 微服务和微软是啥关系？

3. 容灾和聊斋的关系是啥？

从现在起，大家要努力回忆，问自己问题，带着问题，一起继续。在接下来的学习过程，你的参与度就会更高，收获将更大。

我们先看一下今天学习的主要内容。

第一部分，我们先回亿一下前两次GMP培训的内容；

第二部分，平台使用到的关键技术；

第三部分，安全相关的机制；

第四部分，部署的种种方式。

这是今天的主要内容，是不是很少，我们不求大而全，大家今天每人弄明白两个知识点，我认为中午就可以给自己加个鸡腿。

相对于俗话说的“见人说人话，见鬼说鬼话”，此处的“人话”对应的则是“书面话”。书面语很好理解。用书面语讲书面内容，我想这个比较容易，我们如何用人话，把书面语讲出来，让客户听明白，这个可能就比较考验我们对知识的理解程度了。当你作为一个销售与客户交流的时候，不管对方是商务、技术、采购等等角色，你都能把我们的优势正确的传递给对方，我想，这个时候，这场谈判你是被加分的。其实，所谓的“人话”不在于多高大上、也不在于多fashion，而在于对方能否真正听得懂，从而打动他，这点很关键。

关键技术

JAVA

JAVA为面向对象的语言。

Java语言是一种“Everything is object”的语言，它能够直接反应现实生活中的对象，例如火车，动物等，通过它，开发人员编写程序更为容易。问大家个问题，知道为什么程序员什么不找对象，不着急找到方像么，因为他们具有寻找资源的能力，另外一点才是重点，他们可以快速的NEW一个对象，每天都在面象对象。

平台无关性

Java为解释型语言，无论是在Windows,Linux还是MacOS等其他平台上编译器会把java代码变成“中间代码”，然后在Java虚拟机（JVM）上解释运行。由于中间代码与平台无关，所以Java语言可以“一次编译，到处运行”。

JAVA与JAVASCRIPT的关系就好比，雷峰和雷锋塔的关系——也就是没有一毛钱的关系。他们都是95年出生的。因为两家公司有合作关系，最后JAVASCRIPT希望自己更像JAVA，所以起了这个名字。

微服务

微服务架构的几个特点：

小——粒度小，且专注一件事情；

松——松耦合，可独立部署；

独——单独的进程；

轻——轻量级通信机制，不占用较大的网络资源、带宽资源。

根据他的特点，我们对于微服务架构应该比较清楚了吧？嗯？没太明白，不具象？好！我们先放下，先了解点别的，一会儿再过来看。

单机结构

我想大家最最最熟悉的就是单机结构，一个系统业务量很小的时候所有的代码都放在一个项目中就好了，然后这个项目部署在一台服务器上就好了。整个项目所有的服务都由这台服务器提供。这就是单机结构。

来看一下，给大家同步过的这几个站点。因为目前的需求是比较简单的，三个站点使用一个程序、一个数据库、一个站点。部署在一台机子上，独立运行。那么，单机结构有啥缺点呢？我想缺点是显而易见的，单机的处理能力毕竟是有限的，当你的业务增长到一定程度的时候，单机的硬件资源将无法满足你的业务需求。此时便出现了集群模式，往下接着看。

集群结构

集群模式在程序猿界有各种装逼解释，有的让你根本无法理解，其实就是一个很简单的玩意儿，且听我一一道来。单机处理到达瓶颈的时候，你就把单机复制几份，这样就构成了一个“集群”。集群中每台服务器就叫做这个集群的一个“节点”，所有节点构成了一个集群。每个节点都提供相同的服务，那么这样系统的处理能力就相当于提升了好几倍（有几个节点就相当于提升了这么多倍）。但问题是用户的请求究竟由哪个节点来处理呢？最好能够让此时此刻负载较小的节点来处理，这样使得每个节点的压力都比较平均。要实现这个功能，就需要在所有节点之前增加一个“调度者”的角色，用户的所有请求都先交给它，然后它根据当前所有节点的负载情况，决定将这个请求交给哪个节点处理。这个“调度者”有个牛逼了名字——负载均衡服务器。集群结构的好处就是系统扩展非常容易。如果随着你们系统业务的发展，当前的系统又支撑不住了，那么给这个集群再增加节点就行了。

我们再继续看售前站点：为了应对国际化需求，兼顾国内国外用户的访问速度，我们部署了两个节点。节点1是我们自己的机房。节点2部署在美国。但是，当你的业务发展到一定程度的时候，你会发现一个问题——无论怎么增加节点，貌似整个集群性能的提升效果并不明显了。这时候，你就需要使用微服务结构了。

分布式结构

先来对前面的知识点做个总结。从单机结构到集群结构，你的代码基本无需要作任何修改，你要做的仅仅是多部署几台服务器，每台服务器上运行相同的代码就行了。但是，当你要从集群结构演进到微服务结构的时候，之前的那套代码就需要发生较大的改动了。    OK，下面开始介绍所谓的分布式结构。分布式结构就是将一个完整的系统，按照业务功能，拆分成一个个独立的子系统，在分布式结构中，每个子系统就被称为“服务”。

再看一下我们的PS在线站点的例子，按照微服务的思想，我们需要按照功能模块拆分成多个独立的服务，如：团队博客、需求提交表单、乐学堂站点、网址导航、内容管理系统、下载服务等等。这一个个服务都是一个个独立的项目，可以独立运行。

这样的好处有很多：

1、 系统之间的耦合度大大降低，可以独立开发、独立部署、独立测试，系统与系统之间的边界非常明确，排错也变得相当容易，开发效率大大提升。

2、 系统之间的耦合度降低，从而系统更易于扩展。我们可以针对性地扩展某些服务。    假设用户量大大提升，我们可以针对性地提升网址导航、博客系统的节点数量，而对于后台管理系统、下载系统而言，节点数量维持原有水平即可。

3、 服务的复用性更高。    比如，当我们将下载系统作为单独的服务后，所有的下载渠道，都可以使用该系统作为下载系统，无需重复开发。APP、小程序、网站等。

通过分布式，我们把一些服务拆分开了。但是还不够细。但是性能等指标提升了一大截一大截。微服务肯定是分布式部署的，分布式部署的应用不一定是微服务架构的，比如集群部署，它是把相同应用复制到不同服务器上，但是逻辑功能上还是单体应用。

只要是一堆机器，就可以叫集群，他们是不是一起协作着干活，这个谁也不知道；一个程序或系统，只要运行在不同的机器上，就可以叫分布式，嗯，C/S架构也可以叫分布式。

B/S架构

即Browser/Server（浏览器/服务器）结构，优点：客户端零维护；系统扩展容易；在电脑可上网的前提下，可以在任何操作系统上使用，并且不需要安装专门的软件 。

C/S架构

即Client/Server(客户机/服务器)结构，优点：交互性强，客户端有着一套完整的应用程序，相对B/S有着更加强大的功能，还可以实现子程序之间的切换；安全性强；处理信息能力强，C/S的通信量相对B/S是少了很多的；速度较快，更加利于处理大量数据。缺点：    客户端要安装专用的客户端软件；每当系统升级时，每一台客户机需要重新安装；操作系统可能会有限制。

消息队列

消息（Message）是指在应用间传送的数据。消息可以非常简单，比如只包含文本字符串，也可以更复杂，可能包含嵌入对象。消息队列（Message Queue）是一种应用间的通信方式，消息发送后可以立即返回，由消息系统来确保消息的可靠传递。消息发布者只管把消息发布到 MQ 中而不用管谁来取，消息使用者只管从 MQ 中取消息而不管是谁发布的。

这样发布者和使用者都不用知道对方的存在。系统A只负责把数据写到队列中，谁想要或不想要这个数据(消息)，系统A一点都不关心。

科普：

把数据放到消息队列叫做生产者

从消息队列里边取数据叫做消费者

消费者怎么从消息队列里边得到数据？有两种办法：生产者将数据放到消息队列中，消息队列有数据了，主动叫消费者去拿(俗称push) 消费者不断去轮训消息队列，看看有没有新的数据，如果有就消费(俗称pull)

消息队列是一种应用间的异步协作机制。 也就是今天我们提到的另外一个关键技术：异步通信。

我们GMP平台使用的消息队列叫rabbitmq——兔子消息队列。主要有以下特点：

可靠性（Reliability）：RabbitMQ 使用一些机制来保证可靠性，如持久化、传输确认、发布确认。

消息集群（Clustering）：多个 RabbitMQ 服务器可以组成一个集群，形成一个逻辑 Broker高可用（Highly Available Queues）    队列可以在集群中的机器上进行镜像，使得在部分节点出问题的情况下队列仍然可用。

多语言客户端（Many Clients）：RabbitMQ 几乎支持所有常用语言，比如 Java、.NET、Ruby 等等。

通信，我们问个问题，大家想想，哪些行为属于通信。古今中外都可以。烽火台、狼烟。狼烟是什么，粮粪点燃产生的烟，就是狼烟。用以传输信息。还有哪些典故，烽火戏诸候。刚才我们说的兔子消息队列，通信方式就是属于异步通信。对应的应该还有同步通信。接下来我们分别了解一下这两种通信方式。

异步通信

异步通信的定义，发送方和接收方没有统一的时钟节拍，各自按照自己的节奏工作。我们还拿烽火台举例。通信双方通信时间不固定，有时三秒发一次，有时三天发一次。适用异步。烽火台A，5分钟发一次信息，烽火台B每2分钟收一次信息。也就是 你在要5分发的信息，2分的时候，敌人进攻了，但是A的发送时间是5分，B，也不会接收，因为就没有给他发。说有敌人来了，不好意思。B不会马上接收。等到10分的时候，B接收到了，但是敌人已经把刀架在她的脖子上了，所以，这种情况，不适用异步通信机制。异步通信时，接收方不必一直在意发送方，发送方需要发送信息时会给接收方一个信息开始的信号。接收方收到起始信息号后就认为后面紧跟着是有效的信息。才会开始注意接收信息，直到收到发送方发过来的结束标志。

同步通信

同步通信优势。通信双方信息交互频率固定。经常通信。也就是说白了，多长时间发一次，多长时间接一次，这是固定的。或者是经常通信。通信特别多。都可以使用同步通信。同步通信相当于，别人一直盯着你。结果你说一句，停五分钟，这样对于别人就是资源的浪费。你把接收方给坑了。哎，有个事，我和你说一下。然后，他一直等着。

数据库

全球范围内，传统数据库三大厂商分别为Oracle、IBM、Microsoft，其中Oracle全球最大，占据中国数据库40%以上的市场份额。关系型数据库常见的有Oracle，SQLServer，DB2，Mysql，除了Mysql大多数的关系型数据库如果要使用都需要支付一笔价格高昂的费用，即使是免费的Mysql性能也受到了诸多的限制。而对于NoSQL数据库，比较主流的有redis，HBase，MongoDb等产品，通常都采用开源的方式，不需要像关系型数据库那样，需要一笔高昂的花费。

NOSQL 为了高性能、高并发而生，忽略掉影响高性能，高并发的功能我们先说一下这家公司。

ORACLE

在我年少无知的时候，其实我一直以为甲骨文是一家考古研究企业、国企。直到我知道，甲骨文和ORACLE是一家企业的时候，我还是不能接受。大家都知道甲骨文最早出现是商朝。首次发现是由清末的张之洞在河南安阳发现的，1899年。这么有中国5000年文化特色的名字，怎么可能相关联呢。其实，Oracle公司在全世界所有国家和地区都只有Oracle这个英文名字，或者是当地语言的音译。只有在中国，Oracle才有一个本地语言词汇的名字，据说是有人向Larry解释过其中渊源，于是Oracle在中国注册的所有法人都是“甲骨文xxxx“…… 以上是入职甲骨文的朋友，参加新人培训听来的。

版本升级：oracle8i，oracle9i，oracle10g，oracle11g，oracle12c

MySQL

MySQL被广泛的应用在Internet上的大中小型网站中。由于体积小、速度快、总体拥有成本低，开放源代码商业版不遵守GPL协议，社区版遵守GPL协议可以免费试用。

随着各种政策利好，国外企业的“骄傲放纵”，正是国产数据库奋起直追的好机会。比如行业最强的Oracle，其过去几年数据库自身技术发展并不多，一直在啃原来的看家本领继而出现云计算转型不力、出现全球裁员等现象。

国产数据库

TiDB

TiDB：高度兼容mysql，几乎无需修改代码，TiDB 在大数据量下复杂查询方面，相比 MySQL 有绝对的性能优势。具备「分布式强一致性事务、在线弹性水平扩展、故障自恢复的高可用、跨数据中心多活」等核心特性 。

OceanBase

OceanBase：完全自主研发的金融级分布式关系数据库。

OceanBase：对传统的关系数据库进行了开创性的革新。

在普通硬件上实现金融级高可用，在金融行业首创“三地五中心”城市级故障自动无损容灾新标准，同时具备在线水平扩展能力，创造了 6100 万次/秒处理峰值的纪录。

2019年10月，OceanBase 以 6088 万 tpmC 值的成绩，打破数据库基准性能测试的世界纪录，荣登 TPC-C 基准测试性能榜首。

2019年10月，OceanBase在TPC-C的测试中，以60880800tmpC的成绩战胜了榜上的Oracle，后者的成绩是30249688tpmC，登顶夺冠；这件事情又让业界对国产数据库的关注提到了一个很高的高度。兼容mysql大部分语法，也实现了mysql大部分的语法。兼容mysql不是Oceanbase的主要目的是兼容ORACLE。

GaussDB

华为GaussDB将AI能力植入到数据库内核的架构和算法中，为用户提供更高性能、更高可用、更多算力支持的分布式数据库。提供PB(Petabyte，2的50次方字节)级别数据量的处理能力。

2019年7月，华为GaussDB在浙江移动核心系统成功商用；

2019年8月，华为GaussDB在工商银行、招商银行、民生银行获得客户采用并获成功；

2019年9月，在张家港农商银行新一代核心业务系统上线；目前金融行业已有成功案例。

这是在国内银行首次在传统核心业务系统场景下，采用国产分布式数据库，打破了该领域对国外数据库的长期依赖，响应了国家对金融核心领域技术自主可控的要求。相比之前的甲骨文数据库，张家港农商银行还收获了降低成本的好处。原因是，甲骨文对网络环境要求高，需要在网络特别好的环境里面才跑的很好。国产分布式数据库不怎么吃网络，对硬件的要求变小了，成本量级级别的减少。这也是我们的主要卖点，帮他们省钱。

缓存

比较常见的，是根据缓存与应用的藕合度，分为 local cache（本地缓存）和 remote cache（分布式缓存）。

Redis

Redis的性能极高，读的速度是110000次/s，写的速度是81000次/s，支持事务，支持备份，丰富的数据类型。

任何事情都是两面性，Redis也是有缺点的：

1、由于是内存数据库，所以单台机器存储的数据量是有限的，需要开发者提前预估，需要及时删除不需要的数据。

2、当修改Redis的数据之后需要将持久化到硬盘的数据重新加入到内容中，时间比较久，这个时候Redis是无法正常运行的。

中间件

需要利用服务的人（前端写业务的），不需要知道底层逻辑（提供服务的）的具体实现，只要拿着中间件结果来用就好了。我开了一家炸鸡店（业务端），然而周边有太多屠鸡场（底层），为了成本我肯定想一个个比价，再综合质量挑选一家屠鸡场合作（适配不同底层逻辑）。由于市场变化，合作一段时间后，或许性价比最高的屠鸡场就不是我最开始选的了，我又要重新和另一家屠鸡场合作，进货方式、交易方式等等全都要重来一套（重新适配）。然而我只想好好做炸鸡，有性价比高的肉送来就行。于是我找到了一个专门整合屠鸡场资源的第三方代理（中间件），跟他谈好价格和质量后（统一接口），从今天开始，我就只需要给代理钱，然后拿肉就行。代理负责保证肉的质量，至于如何根据实际性价比，选择不同的屠鸡场，那就是代理做的事了。

安全相关

SHA家族

SHA家族：由美国国家安全局（NSA）所规划。该算法是美国的政府规范算法，后四者有时并称为SHA-2。曾被视为是MD5（更早之前被广为运用的杂凑函数）的后继者。SHA-1的安全性现在被密码学家严峻质疑，有学者曾经爆出NSA在SHA-1留下的后门。SHA256是指生成256位的哈希——一个16进制字符表示4位二进制字符。SHA-256是比特币一些列数字货币使用的加密算法，基本原理就是把任意长度的输入，通过Hash算法变成固定长度的输出。从hash值不可以反向推导出原始的数据。

安全是相对～

国内比较大的CMS系统的配置文件，像新闻总署、国家海洋局，都在使用，我这个也是我之前做过的项目。这样会影响他的使用吗，不会。

非对称加密

DES向AES的过渡过程，非对称加密算法是一种密钥的保密方法。非对称加密算法需要两个密钥：公开密钥（publickey：简称公钥）和私有密钥（privatekey：简称私钥）。公钥与私钥是一对，如果用公钥对数据进行加密，只有用对应的私钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。

国密

下面，我们来说说国密算法，大家觉得1、2、3、4，他们是什么关系，父子还是兄弟？其实他们是国家密码管理局的四个儿子。几兄弟主要负责国家信息安全中的加密。老4是2006年出生，原名叫SMS4，2012年被他爸改成了SM4，名字虽然洋气，但是地地道道的中国人。老大主要负责硬件的加密，他的算法和其它三兄弟都不同，除老大外，其它人的算法都是公开的，只有老大却埋藏得很深。老二负责非对称加密，老四负责对称加密，老三负责哈希算法。

平台部署

继911之后，四川大地震又一次给数据中心工作者上了一堂鲜活的安全教育课，眼睁睁看着一些企业由于关键业务数据遭到破坏导致整个企业的破产，也许这个时候才能深刻感觉到数据是企业生命的真谛所在。

2019.6.02：AWS中国区光缆被挖断，导致三星、小米等众多企业服务不可用；

2019.3.23：施工队挖断腾讯光纤，致腾讯旗下100多款游戏受影响，损失大了；

2015.5.27：由于杭州萧山区某地光纤被挖断，造成少部分用户无法使用支付宝。

我这里只列出来了几家大公司所涉及到的光缆被挖事故，其余还包括什么广电光缆被挖，社保局光缆被挖就不列了，大家感兴趣，自己去搜索。我们发现，“公司再大，也怕施工队”当然我们不能怪施工队，我们要考虑怎么预防这种现象呢？

同城容灾

同城容灾是在同城或相近区域内 （ ≤ 200K M ）建立两个数据中心 : 一个为数据中心，负责日常生产运行 ; 另一个为灾难备份中心，负责在灾难发生后的应用系统运行。同城灾难备份的数据中心与灾难备份中心的距离比较近，通信线路质量较好，比较容易实现数据的同步 复制 ，保证高度的数据完整性和数据零丢失。同城灾难备份一般用于防范火灾、建筑物破坏、供电故障、计算机系统及人为破坏引起的灾难。

异地容灾

异地容灾主备中心之间的距离较远 （＞ 200KM ) ， 因此一般采用异步镜像，会有少量的数据丢失。异地灾难备份不仅可以防范火灾、建筑物破坏等可能遇到的风险隐患，还能够防范战争、地震、水灾等风险。由于同城灾难备份和异地灾难备份各有所长，为达到最理想的防灾效果，数据中心应考虑采用同城和异地各建立一个灾难备份中心的方式解决。

结合近年国内出现的大范围自然灾害，以同城双中心加异地灾备中心的 “两地三中心”的灾备模式也随之出现，这一方案兼具高可用性和灾难备份的能力。在同城建设两个数据中心，同时为外提供业务服务，同时在异地建设灾备中心，用于数据的备份。分布式双活数据中心方案可以帮助客户找到优化投资利用率、保证业务连续性的新思路。适用于对业务连续性要求较高的应用，通过集成同城双活与异地灾备两种解决方案，既能实现数据零丢失和故障自动切换，又能抵御局部灾难带来的影响。

特点：

同城两个站点之间的高可用提供数据零丢失、实现灵活切换的第一层保护。

异地数据中心之间的灾备功能实现第二层保护。

软件定义的网络与存储可提供最大的灵活性。我们看下支付宝的解决方法 ，毕竟它老人家在2015年就经历过这种惨况了。

2018年9月20日，杭州云栖大会ATEC主论坛现场上演了一场特别的技术秀。蚂蚁金服副CTO胡喜现场模拟挖断支付宝近一半服务器的光缆。结果只过了26秒，模拟环境中的支付宝就完全恢复了正常。

解决办法就是三地五中心，这是一种机房架构，即在三座城市部署五个机房，一旦其中一个或两个机房发生故障，依靠技术可以奖故障城市的流量全部切换到运行正常的机房。

容灾指标

衡量容灾系统的主要指标有 RPO （ Recovery Point Object ，灾难发生时允许丢失的数据量）、 RTO （ Recovery Time Objective ，系统恢复的时间）、容灾半径（生产系统和容灾系统之间的距离）以及 ROI(Return of Investment ，容灾系统的投入产出比 ) 。

RTO 是指“将信息系统从灾难造成的故障或瘫痪状态恢复到可正常运行状态，并将其支持的业务功能从灾难造成的不正常状态恢复到可接受状态”所需时间，其中包括备份数据恢复到可用状态所需时间、应用系统切换时间、以及备用网络切换时间等，该指标用以衡量容灾方案的业务恢复能力。例如，灾难发生后半天内便需要恢复，则 RTO 值就是十二小时。

容灾半径是指生产中心和灾备中心之间的直线距离，用以衡量容灾方案所能防御的灾难影响范围。显然，具有零RTO、零RPO 和大容灾半径的灾难恢复方案是用户最期望的。但是，受系统性能要求、适用技术以及成本预算等方面约束，综合考虑ROI后，才能确定一个可行的容灾架构部署方案。其实我们在做的每一件事事情，都是要评估ROI。很感谢大家给我这个学习的机会。

非常感谢大家。

愿你有力，愿你前行~