业务支持

宜信公司从2018年初开始建设容器云，至今，容器云的常用基本功能已经趋于完善，主要包括服务管理、应用商店、Nginx配置、存储管理、CI/CD、权限管理等，支持100+业务线、3500+的容器运行。伴随公司去VMware以及DevOps、微服务不断推进的背景，后续还会有更多的业务迁移到容器云上，容器云在宜信发挥着越来越重要的作用。本次分享主要介绍宜信容器云平台的背景、主要功能、落地实践及未来规划。 一、宜信容器云平台背景 宜信容器云平台的建设背景主要包括： 提高资源利用率。容器云建设之前，每台物理机上平均运行的虚拟机大概是20个，使用了容器云之后，每台物理机上平均运行的容器数达到50个；之前的CPU利用率大概在10%左右，迁移到容器云后，CPU利用率提高到20%以上，整个资源利用率得到了极大的提升。 提升服务可靠性。传统的虚拟机运维方式下，当机器宕机或系统故障时，需要运维手动重启虚拟机和服务，整个过程最快需要几十分钟到几个小时才能解决；使用容器云后，通过健康检查的方式，一旦发现有问题就自动重启恢复服务，可以达到分钟级甚至秒级的恢复。 节约成本。通过容器云提高了资源利用率，同时也节约了成本。公司每年会采购一些商业化软件，如虚拟化软件、商业存储等，费用动辄千万。我们基于开源技术自研一套容器解决方案，每年为公司节省上千万的软件采购和维保费用。 弹性伸缩。我们公司每年都会组织财富峰会

在规划相关的项目工作中，近两年我们的项目主要使用的是 Optaplanner 作为规划引擎，其核心也是一个的规划求解器(Solver)。但作为另一个著名开源求解器 Google OR-Tools (下称OR-Tools)也日渐流行。且因Google自带流量的支持，OR-Tools有更多专门研究运筹的学者使用和研究。而Optaplanner则更偏向工程实践上的应用。本文就二者在技术特性、使用方法与场景等方面，列出若干差异。希望为需要使用开源求解器进行项目工作的同行提供初步入门参考与选择。 简介 Optaplanner Optaplanner目前是Apache基金会的一款开源软件,JBOSS社区,基于 Apache 开源软件协议，该协议对商用友好，因此可以自由地将该技术的部门或全部应用于商用软件项目中。该项目目前由受雇于Redhat的团队在维护.其创业人 Geoffrey De Smit 先生作为该项目的Leader. 其实Optaplanner已发展了十余年，最初是由Geoffrey在参加运筹规划大赛中，针对各种竞赛题目 开发的一个求解器。后来将它贡献给开源社区，并作为开源项目一直维护至今，其版本发布仍十分高效，除进行一些对用户透明不可视的算法与架构优化外，不时还有极具价值的新功能与新特征发布，如7.09版本发布的多线程支持，本人认为是极具里程碑意义的新特征

当下，Spark已经在国内得到了广泛的认可和支持：2014年，Spark Summit China在北京召开，场面火爆；同年，Spark Meetup在北京、上海、深圳和杭州四个城市举办，其中仅北京就成功举办了5次，内容更涵盖Spark Core、Spark Streaming、Spark MLlib、Spark SQL等众多领域。而作为较早关注和引入Spark的移动互联网大数据综合服务公司，TalkingData也积极地参与到国内Spark社区的各种活动，并多次在Meetup中分享公司的Spark使用经验。本文则主要介绍TalkingData在大数据平台建设过程中，逐渐引入Spark，并且以Hadoop YARN和Spark为基础来构建移动大数据平台的过程。 初识Spark 作为一家在移动互联网大数据领域创业的公司，时刻关注大数据技术领域的发展和进步是公司技术团队必做的功课。而在整理Strata 2013公开的讲义时，一篇主题为《An Introduction on the Berkeley Data Analytics Stack_BDAS_Featuring Spark,Spark Streaming,and Shark》的教程引起了整个技术团队的关注和讨论，其中Spark基于内存的RDD模型、对机器学习算法的支持

一、序言 本文从产品经理的角度出发，对产品经理的安全职责、产品驱动安全的内涵、工作内容、工作方法、所需安全资源、以及产品经理的安全工作量进行了分析。希望所有产品经理在没有心理负担的情况下，有目标、有方法、有资源推进产品安全建设。 二、背景 安全是软件产品天然属性的一部分，“无安全不金融”，对于金融软件产品而言，安全尤为重要，因为客户总是能够从各种安全漏洞联想到他的金融资产安全和个人信息安全。以前偶尔会在一些安全沙龙或峰会听见同行吐槽，“信息安全说起来重要、做起来次要、忙起来不要”。吐槽背后的原因很复杂，其中很重要的一点是跟产品经理安全意识淡薄、不清楚如何推进产品安全建设有关，比如不重视产品安全属性、产品安全需求不明确、产品安全资源不充分、产品安全建设无从下手等。本文主要站在产品经理的角度，从产品经理能力维度出发，探讨产品经理如何推动产品的安全性建设。 众所周知，安全性作为软件产品的天然属性，从产品定义与规划角度来看，产品经理对产品安全负有不可推卸的责任，但产品经理如何履行自己的安全职责，业界还没有给出一个清晰可行的行动方案。 目前，软件产品安全需求通常是基于开发人员和安全人员的职业常识提出相应的解决方案，比如目前业内比较通用的敏感信息五要素分析方法： 1 2 3 4 5 姓名 身份证号 电话号码 银行卡信息 联系地址 这种方法简单易行，但往往不能涵盖所有的敏感信息，比如

中间件（middleware）是介于 应用系统和系统软件之间 的一类软件，它使用系统软件所提供的 基础服务（功能） ，衔接网络上应用系统的各个部分或不同的应用，能够达到 资源共享、功能共享 的目的。目前，它并没有很严格的定义，但是普遍接受IDC的定义：中间件是一种独立的系统软件服务程序， 分布式应用软件借助这种软件在不同的技术之间共享资源 ，中间件位于客户机服务器的操作系统之上，管理计算资源和网络通信。从这个意义上可以用一个等式来表示中间件：中间件=平台+通信，这也就限定了 只有用于分布式系统中才能叫中间件 ，同时也把它与支撑软件和实用软件区分开来。 简介 中间件是一类连接软件组件和应用的计算机软件，它包括 一组服务 。以便于运行在一台或多台机器上的多个软件通过网络进行交互。该技术所提供的互操作性，推动了一致 分布式 体系架构的演进，该架构通常用于支持并简化那些复杂的 分布式应用程序 ，它包括 web服务器、 事务 监控器 和 消息队列 软件 。 中间件(middleware)是 基础软件 的一大类，属于可复用 软件 的范畴。顾名思义，中间件处于 操作系统 软件 与用户的 应用软件 的中间。 中间件在操作系统、网络和 数据库 之上， 应用软件 的下层，总的作用是为处于自己上层的 应用软件 提供 运行与开发的环境 ，帮助用户灵活、高效地开发和集成复杂的应用软件

前言 大数据背景下，传统关系型多维分析 ROLAP 引擎遇到极大挑战，因而链家转向基于 Hadoop 生态的 MOLAP(Kylin)及 HOLAP （多引擎）。在架构师实践日北京站中，链家大数据集群架构组负责人邓钫元进行演讲，分享了链家在多维分析引擎方面的一些实践经验，主要从 OLAP 的背景和简介、链家多维分析架构演进和展望、OLAP 平台链路优化这三部分来介绍。 一、OLAP 的背景和简介 > > > > 1. OLAP vs OLTP OLAP 翻译成中文叫 联机分析处理 ，OLTP 叫 联机事务处理 。OLTP 它的核心是事务，实际上就是我们常见的数据库。我们业务数据库就是面向于事务。它的并发量会比较高，但是操作的数据量会比较小。它是实时更新的。数据库的设计会按照 3NF 范式，更高的话可能会按照 BC 范式之类的来做。而 OLAP 的核心是分析，面向应用是分析决策，需要分析的数据级会非常大，可能 TB，甚至 PB 都会有。它的数据更新会稍微慢一些，它的设计一般是反范式的，因为面向分析。常见的是雪花模型和星型模型。 实际上 OLAP 是什么呢？ 非常简单，就是一个 SQL，这里按照两个维度，一个 returnflag，一个 orderstatus 来做 Group By，然后做一下 Sum，Group By 这段就叫维度，From 这段叫做指标，非常简单。 > > > >

客户端自动化特点 客户端的自动化，通常做过的人都不是很愿意深入讨论。因为除了功能和逻辑之外，不得不面对各种界面变化，各种和环境交互，各种兼容问题以及想不到灰色地带，就算这样，也找不到太多有效的bug。然而即便如此，客户端的自动化必须去做，尤其是GUI的。它的自动化特点是： 复杂 成本高 不容易发现问题 技术要求高 架构很难通用 下面，从一些基本的东西开始一点点的讨论客户端GUI测试的一些问题和处理办法，以及自动化架构设计的一些思路。事实上就像上面说的，GUI的测试并不是为了发现bug，而是回归的一种方式，作为保证而已——它过了不能说明质量多么好，但是不过，质量肯定不达标。即使在微软内部，客户端的GUI一样不是个受欢迎的家伙，通常用来做BVT的测试（或一些重要性回归，冒烟等）。 客户端自动化简述 这里并不花过多的笔墨介绍什么是客户端，或者如何分类的种种——这些东西教材和网上的东西一坨一坨很多很多，这里可能“漫谈”的，是实际工作中，客户端和GUI自动化中可能遇到的一些底层技术，基本上原理，架构设计方法以及一些项目存在困惑，这些方面的一些处理的方法。 最早的自动化 我个人认为所谓的计算机行业的自动化，是一直跟着这个行业的发展在走，比如下面的这些： 老式计算机——CPU计算： 最早自动解决手工分配穿孔的卡片问题 内存分配任务调度：操作系统的核心就是内存和任务的自动管理 系统配置Loader

产品首页 云计算基础 弹性计算 云服务器 云服务器 ECS 从安全型到内存型、从进阶型到入门型的云服务器 弹性裸金属服务器（神龙） 兼具虚拟机的弹性和物理机的高性能、安全物理隔离、分钟交付、云产品全兼容 块存储 可弹性扩展、高性能、高可靠的块级随机存储 轻量应用服务器 可快速搭建且易于管理的轻量级云服务器 GPU 云服务器 GPU实例、强大的计算性能、弹性按需扩展 FPGA 云服务器 FPGA实例、低时延可编程硬件加速服务 专有宿主机 安全合规，构建公共云上的专有资源池 高性能计算 HPC 超级计算集群 支持RDMA提供极致并行计算性能实例规格 弹性高性能计算 E-HPC 加速深度学习、渲染和科学计算的 GPU 物理机 容器服务 容器服务 支持微服务架构、全生命周期管理的Docker服务 容器服务 Kubernetes 版 提供高性能可伸缩的容器应用管理能力，支持企业级 Kubernetes 容器化应用的全生命周期管理 弹性容器实例 ECI 提供敏捷安全的 Serverless 容器运行服务 容器镜像服务 简化了Registry的搭建运维工作，支持多地域的镜像托管 弹性编排 弹性伸缩 自动调整弹性计算资源的管理服务 资源编排 复杂环境部署利器，提供资源批量复制、创建和配置 Serverless 函数计算 一个事件驱动的全托管计算服务，通过函数计算，无需管理服务器等基础设施

你知道的越多，你不知道的越多 点赞再看，养成习惯 本文 GitHub https://github.com/JavaFamily 已收录，有一线大厂面试点脑图、个人联系方式和技术交流群，欢迎Star和指教 前言 消息队列 在互联网技术存储方面使用如此广泛，几乎所有的后端技术面试官都要在 消息队列 的使用和原理方面对小伙伴们进行360°的刁难。 作为一个在互联网公司面一次拿一次Offer的面霸，打败了无数竞争对手，每次都只能看到无数落寞的身影失望的离开，略感愧疚（ 请允许我使用一下夸张的修辞手法 ）。 于是在一个寂寞难耐的夜晚，我痛定思痛，决定开始写 《吊打面试官》 系列，希望能帮助各位读者以后面试势如破竹，对面试官进行360°的反击，吊打问你的面试官，让一同面试的同僚瞠目结舌，疯狂收割大厂Offer！ 捞一下 消息队列系列前面两章分别讲了 消息队列 的基础知识，还有比较常见的问题和常见分布式事务解决方案，那么在实际开发过程中,我们使用频率比较高的消息队列中间件有哪些呢？ 帅丙我工作以来接触的消息队列中间件有 RocketMQ 、 Kafka 、 自研 ，是的因为我主要接触的都是电商公司，相对而言业务体量还有场景来说都是他们比较适合，再加上杭州阿里系公司偏多，身边同事或者公司老大基本都是阿里出来创业的，那在使用技术栈的时候 阿里系的开源框架 也就成了首选。

本文转载自：http://blog.csdn.net/u013412535/article/details/43462537 ETL ，是英文 Extract-Transform-Load 的缩写，用来描述将数据从来源端经过萃取（extract）、转置（transform）、加载（load）至目的端的过程。 ETL 一词较常用在 数据仓库 ，但其对象并不限于 数据仓库 。 ETL负责将分布的、异构数据源中的数据如关系数据、 平面数据文件等抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础。 ETL是数据仓库中的非常重要的一环。它是承前启后的必要的一步。相对于关系数据库，数据仓库技术没有严格的数学理论基础，它更面向实际工程应用。所以从工程应用的角度来考虑，按着物理数据模型的要求加载数据并对数据进行一些系列处理，处理过程与经验直接相关，同时这部分的工作直接关系数据仓库中数据的质量，从而影响到联机分析处理和数据挖掘的结果的质量。 数据仓库是一个独立的数据环境，需要通过抽取过程将数据从联机事务处理环境、外部数据源和脱机的数据存储介质导入到数据仓库中；在技术上，ETL主要涉及到关联、转换、增量、调度和监控等几个方面；数据仓库系统中数据不要求与联机事务处理系统中数据实时同步，所以ETL可以定时进行。但多个ETL的操作时间