五. 公共基础技术

技术平台与公共基础技术，是IT相关从业人员各个角色都相关，应当要掌握的一些基础。本文中只针对各类服务的应用约定和需要注意的点进行说明。

5.1 IAAS层

不管基于什么样的云服务部署形态。IAAS层提供的都是三类服务： 计算(服务器)、存储、网络。

5.1.1 计算（服务器）

• 除非有特别限定条件，服务器的操作系统应当使用 Linux 操作系统。 Linux 操作系统中，首选 mini 安装的 centos 当前新稳定版。

服务器操作系统限定用 linux 有很多方面的原因。其中一个重要的原因是，我们希望所有服务器端的应用部署都是容器化的（不管是不是有 k8s ）。而windows server 不管是作为容器的 host还是打为容器都太大，并且目前windows 上的容器技术还是不太成熟 。

centos 并不是一个最好的服务器操作系统发行版，首选centos 只是因为其在国内的群众基础比较好。

• 所有架构师必须关注分布式并行计算，在各个层面都要考虑计算的并行化，分布式的情况。

计算靠的是CPU， 而CPU的单核性能提升的时代已经过去。响应性能的提升，吞吐量的提升，都只能通过多核心协同，多服务器协同进行。特别是面向较多用户量的，访问量具备较大弹性的。水平扩展性是性能扩展的最大考量因素。

• CPU核与内存配比的经验参数

多年以来， java 作为后台服务的主导语言，吃内存已经成为大家习以为常的事。因而服务器资源的部署分配比较随意。给出一个配比的参考经验参数：

• java web ， CPU 内存配比为 １CPU核:4G 内存。

• java web 应用，正常情况下 1CPU核:25并发线程：250同时在线用户数。这是一个比较传统的保守值，通过异步IO，数据库存储的优化可以得到更大的并发用户数支撑。

• 数据库服务器的资源配比要考虑数据量与数据库类型，因为大量的内存是用来做IO缓存的,内存数据库就更不用说了,数据库的CPU核数与同时连接的用户数相关,内存配置与数据量的预估相关。

• 计算存储分离的理念

简单的说计算存储分离，就是计算的程序与其管理依赖的数据不要强依赖的放到一起，程序与数据可以分别的分发、关联。计算与存储分离是一个比较大的概念。大到大数据平台，云平台的设计，小到应用程序的数据存储分布。对于一个做应用的公司来说，我们的架构师们需要的是理解计算存储分离的优劣势。并在系统的设计中，尽可能的将数据存储独立到应用之外（至少逻辑上），最典型的例子是集群环境下， 应用程序不可以将数据存储于一台服务器（或容器）的本地存储。

5.1.2 存储

存储也是一个广泛的概念，一般情况下我们谈IAAS层的存储， 从应用角度来说，主要是三类：

• 块存储：提供祼盘给主机（或容器）。主机可进行分区，格式化，LVM等作为本地文件系统或者特殊的数据库直接用裸盘进行存储。

• 对象存储：即一个key ,对应一个文件对象。最常见的协议如 s3, Swift ，以及阿里的OSS。

• 文件系统：基于 POSIX 提供已经格化好的文件系统，通过网络作为一个特殊的文件系统进行访问或mount到主机（或容器）。常见的是 NFS, HDFS 。

在具体的存储实现上来说，这块不是应用开发所关注的。云端存储的发展路线都是在走基于高速网络的分布式存储，存储介质将ssd 盘与机械硬盘根据使用场景进行划分。基于分布式存储对外提供上述的几种存储服务（还可以根据场景进行细分）

架构师需要知道的是常见的存储提供的原理与术语，以在与相关客户方、底层平台的沟通时不至于有术语理解差别。如：

SCSI、FC、DAS 、 NAS、SAN、ISCSI、 VSAN ，SAS，SDS 等。

从应用开发角度来说， 我们的路线是：

• 内网基于 Ceph的分布式存储，同时提供上述的三种存储服务。公有云使用相应云平台的OSS和云盘等存储服务。涉及到互联网内容分发的还需要使用CDN。

• 大数据以及冷数据的存储用 HDFS.

5.1.3 网络

网络涉及到的范围很广，一般人不可能成为网络的专家。对软件开发，架构设计来说，我们需要理解 ：

• TCP IP 协议层栈在不同层次的意义，TCPIP协议栈与ISO 7 层模型的对应；
• 网络负载均衡，三层、四层、七层负载均衡（SLB）的不同；
• 子网,Vlan, NAT，DNS，NTP， 端口映射 ，防火墙，DMZ，VPN,南北向流量，东西向流量等基本概念；
• 进一步的，在公有云上PVC网络的拓扑结构，互联网应用的常见安全防护策略的概念；

上面是对于能力的要求。在具体的项目实施落实中，与网络相关的关键点是：

• 生产环境的服务器，还是必须打开防火墙防护,只开放必要的端口，必要的情况下，设置某些专用端口的白名单，限制其他的接入

5.2 PAAS层与技术平台

这里说的PAAS 层是指中间件等标准化的技术平台服务。常用的是数据库，缓存、消息等中件间、大数据服务以及容器和容器调度服务。在现代化的云平台中,这类服务是直接申请即用,正常情况下不需要手工进行安装调试的。但在私有云的不同场景中，不同的环境会涉及到一些调整。

当前的技术路线，必须考虑云原生开发的兼容性以及自主可控的要求。因而对于各类技术服务，我们做如下的约定：

5.2.1 数据库

不同数据库产品有其不同的特点、约束和应用场景，在当前的情况下，我们要考虑其在云平台上的支持情况和不同的规模情况下的扩展。

5.2.1.1 OLTP 关系数据库

• 除客户方历史遗留或特殊要求的项目外，新建的业务操作型系统，OLTP数据库优先考虑mysql，版本5.7以上，建议8.0以上版本，不得使用 5.7 以下的版本； 大部分的 linux 发行版带的数据库为 MariaDB ,注意用 Oracle的开源 mysql而不是 MariaDB

其实 mysql 与 postgreSQL 这两大开源数据库中，postgreSQL 的功能与性能都更强一些。 mysql 因为历史原因，普及度更高一些，大部分的云数据库也都是兼容 mysql 的语法,包括周边工具如 binlog 支持等，形成了较好的 mysql 生态，因而在未来的数据库生态中， mysql 是逃不过去的一个选择，即使自己的应用不base 在mysql 上，其他的工具软件，平台软件也大量会涉及到mysql（ 如 hadoop 的元数据库）。但mysql 对于复杂的关联查询 ，子查询 等确实有其局限性,一般的CRUD 应用， 单表的数据量在1千万条以下时，mysql的性能不会有太大的问题。在规模更大时，一般采用分库分表，读写分离等方法来改进响应性能。如果具备条件，在云平台上可也可以向分布式 DRDS 方向扩展，私有云环境中，可以向 tidb 集群方式演变。

主要是考虑其生态的问题，建议新项目的数据库Base在 mysql 上。基于这同一个标准，也是为了方便于组件的复用与积累。 当然，总有特殊的情况，如用到地理位置计算，同时在 oltp 的应用中，有复杂的查询查询处理的，这种情况可以考虑选择 postgreSQL。

5.2.1.2 OLAP 数据库

OLAP 数据库我们分为两个场景： 面向大量用户的即时查询交互的，和面向批处理的计算处理。前者一般定位在数据集市（DM）层，后者一般定位在DW，ODS（或称数据湖，贴源层）。前端的交互应用，一般关注的是前者。在OLAP领域，目前主要的技术优化方向在于 列存储、内存存储、与分布式计算（MPP）。而在分布式计算方面，又有是否基于 hadoop 的生态的选择。因而，这些年随着大数据的发展，在OLAP 方面，不管是开源领域，还是商业数据库领域，发展出来很多的选择。

面向批处理的计算处理比较好选择，如果存在有 hadoop部署的场景， hadoop 对于离线加工处理都没有问题。在云场景下，阿里的 maxcomputer ，E-MR ， 腾讯的 TSDB ，华为的 DWS ，直接使用SQL接口的加工处理能满足约大部分的需求。在即时交互查询部分，对于用户体验感受比较敏感，同时也分析型应用的架构基础。

针对我们的实际场景，做如下的约定：

• 没有上大的云平台的客户（虚拟化，祼机），客户没有特殊要求的，小数据量用 postgreSQL (非集群），大数据量用 ClickHouse（3 节点起步） ，客户有遗留的 db2 投资，要求继续用 db2 的，用 db2 11 以上版本，并启用列存储优化

• 在大的私有云平台上，是只能被云平台的云服务所绑架的，基本就不要挣扎了，大的云平台自带的云数据库的优化与运维，肯定比自己要虚拟机资源再搭建的要好。阿里系上 ADS ，华为系上Gauss，腾讯系上 Snova,因为所有的分析型数据库，基本都是从 greenplum的开源基础上开发而来的（阿里的 ADS1.0 兼容mysql 语法，2.0 开始有 Postgre版），因而在产品开发上，我们的分析型数据库的　SQL 语法应当遵循PostgreSQL 的标准

• 尽可能将进行后台处理的资源（离线计算处理，流计算）与面向用户交互查询的数据库分开，所以，不推荐在hadoop 集群上进行OLAP交互分析的选择，尽管有一些可选项如 impala , kylin。包括在星环平台上，如果上ArgoDB,也要将 ArgDB的计算资源与Incepter 的计算资源分开，以保证交互查询不管后台任务的影响

5.2.1.3 时序数据库

时序数据库，用于处理带时间标签(按照时间的顺序变化，即时间序列化)的数据，目前有一个趋势是IOT领域想使用时序数据库（或其他）来取代传统昂贵的实时数据库。但实时数据库与目前的时序数据库还是有不少区别的。一般实时数据库产品的配套非常齐全，通常自带采集工具、适配各种接口协议、具备计算能力及定制化的可视化能力，是一套完整的解决方案。时序数据库仅是对于时点序点数据的存储，主要优势是便宜。

时序数据库主要优势在于对于时间序列的高吞吐量与时序查询的优化。我们没有必要去强推工厂的数采都采用现在的时序数据库，但对于与数采接口，实时监控查询的场景，时序数据是有用的。

另外一个场景是结构化的日志采集与分析，典型的是性能监控。

在具体产品的选择中，小型场景可以用清华开源的 IOT DB ,生产环境下， IOT DB 的稳定性还需要进一步的发展成熟 ，云平台上如果 没有提供的话，应当用 InfluxDB ,公有云或私有云平台上有相应的 IOT DB 的，应当用云平台提供的功能，而不必要自己搭建。

时序数据库中一般存储最近一段时间的数据（几个月），历史数据应当归到 HDFS中。

5.2.1.4 其他数据库

• 针对特定于Hbase 优化的应用（基于key 能快速查找的），可以将应用架构在 Hbase 上 。
• 因为烟草行业不知道为什么的原因。不得使用 MongoDB，我们就不要去踩这个坑了。

5.2.2 缓存

• 缓存有API层面与中间件层面的问题，在中间件的选择上，我们统一到 redis。

统一到 redis 并不是因为其他的选择就不好。只是基于生态的考虑。因为我们考虑的是微服务的场景，所以一般需要从集群化，分布式的角度考虑缓存 ，必须让缓存是可以给多个微服务共用的，因而不要使用进程内缓存（如 ehcache), 除非很明确这个服务就只能是个单实例的。

5.2.3 消息中间件

消息中间件传统上都以 IBM MQ 为主。在企业的具体环境中，需要考虑这个兼容性。如果不需要考虑MQ的兼容性时，新的应用不应当再基于IBM MQ。

从卓信目前的应用特点来说，消息中间件用得比较少。传统企业中使用消息中间件还主要用于信息系统之间的集成交互（典型的如主数据分发）。但在走向微服务架构后，同一个大系统内，不同服务之间的交互，使用消息间件间进行解耦的场景难免会遇到。简单的单机场景下， 其实 AcitveMQ 是最为方便的。但是 AcitveMQ 因为其吞吐量的问题，在大型互联网公司中不受待见。互联网公司的云平台都推他们自己研发优化的消息中间件，在这个生态中，相对来说， Kafka 与 RabbitMQ的普及度更好一点（但腾讯就只支持他自己的 CMQ ）。

• 大数据环境下的流式数据接入,以及日志收集，使用 Kafka 为主。

• 在不需要兼容 MQ 的情况下，首选 RabbitMQ。主要是考虑一般的云平台上有都有对于 RabiitMQ 支持。当然互联网公司的云平台会首推他们的自有产品，如阿里首推 rocketMQ, 腾讯云只有CMQ，但好在消息中间件的迁移一般不困难。一个应用之间的组件之间交互，可直接用单机模式。而作为公共的消息中间件（涉及到与别的公司的应用进行消息集成的），应用之间的消息集成（如主数据异步分发），则必须用镜像集群模式。

另外一个需要说明的场景是IOT设计交互的消息协议 MQTT , 用于IOT设备与云端服务的消息交互，也用于移动端的消息推送。因为MQTT 是一个标准协议，而不是一个产品名称，具体实施中，可用的服务器产品特别多https://github.com/mqtt/mqtt.github.io/wiki/server-support 提供了一个服务器端参考矩阵,各云平台也都相应的云服务支持。从技术栈收敛的角度，在项目应用中，不一定非要选最好的（肯定IBM家的最好，标准是他们牵头制定的），简单场景下直接也就用RabbitMQ 即可。

5.2.4 大数据

1.Hadoop

Hadoop 以前是大数据的代名词，但我们应当清醒的认识到,Hadoop 的相关组件，分别适合干什么，不适合干什么。

对于已经存在星环大数据TDH的客户,在具体的实施项目中，其数据源，数据仓库，肯定是在星环TDH之上的，并尽可能用其企业版的生态工具以提升实施效率，如：

• 使用数据联邦直接连到源数据库上进行数据抽取而不要走 Sqoop,DataX;
• 可通过 Inceptor 的SQL模式，操作 Hbase，Search；
• 使用 workflow 进行数据任务的调度；

同时请注意：

• 不要把用户交互的应用直接连到星环Inceptor上，除非是明确的，单表小于500万条，并且SSD盘作为存储的专用优化Inceptor实例。

切实有海量数据进行加工处理的场景，可以用 Hadoop ，并且星环是我们的首选合作伙伴。

2.云上的大数据

在公有云，私有云平台的场景下，大数据应为是作为单独的功能组件提供的，如阿里的 MaxComputer （实现不兼容Hadoop ,供SQL访问），或腾讯云大数据处理套件TBDS。为了方便于原来使用Hadoop 的用户迁称到公有云，目前又都推出了 如 阿里 E-MapReduce (兼容Hadoop生态)，腾讯云的 云数据仓库套件 Sparkling。因为一般的数据处理基本还不涉及到 hadoop 的API开发层，仍然以SQL为主，在云平台上，没有必要选择 Hadoop 兼容的产品，(因为要考虑开源的兼容性，功能上要弱很多)。

云上的大数据，对应的都有相应的数据加工处理开发，运维监控的工具支持。在数据中台的背景下，云厂商也都发力于数据资产管理与元数据管理。对于客户使用这类全套云平台的场景，我们只能适配使用这些产品，其开发使用的门槛不高，但在资质，商务层面，公司会要安排部分的资质培训，考证。

5.2.4 容器及容器编排

在前述的信息化项目的参考逻辑架构中，容器及容器编排是贯穿于前后端的通用部署基础。

• 我们以后的软件部署，推荐都基于容器化的模式进行部署。

关于容器的特点，优缺点，有很多的资料可以参考。在管理与微服务架构的角度，使用容器化进行部署的最大优势在于，将一个组件当成一个黑盒子进行部署与编排，从而得到一个清晰的服务逻辑拓扑，并能方便的控制服务版本，进行升级、回滚。

• 因为kubernetes（K8s）是事实上的容器编排标准，在具备k8s环境的项目现场，服务部署必须使用k8s

• 所有在公司自有环境中进行开发测试的应用，开发测试环境只提供k8s的开发测试基础设施(db2 ,oracle 等传统数据库除外)

• 客户环境只提供VM，不提供容器服务的，使用 docker-compose工具进行部署编排

关于容器与容器编排使用的具体参考，参见： K8sbook

5.2.5 其他

数据库，缓存，消息中间件是项目开发中最常用到的 PAAS层中间件，除此之外，还有其他的场景。包括：

5.2.5.1 web 服务器

• Web 服务器统一用 Nginx ，不得再使用 Apache。

5.2.5.2 全文检索

• 全文检索统一用 ElasticSearch,简单场景下可以单节点直接跑一个docker 实例。定时刷索引即可,复杂环境下当然上集群，最好是在 k8s 中的集群，易于管理。当然星环平台上的ES服务是一样的。中文分词用 IK插件,有现成的docker镜像