padis平台：Padis是基于Docker的分布式平台，它为平安内部提供了高效、稳定和可靠的计算服务

Padis是基于Docker的分布式平台，它为平安内部提供了高效、稳定和可靠的计算服务。通过使用Docker容器技术，Padis可以实现应用程序的快速部署、灵活扩展和动态管理，从而提高了系统的可用性和可维护性。同时，Padis还采用了Mesos+Marathon框架，实现了资源的统一管理和调度，进一步提高了资源的利用率和系统的稳定性。
在这篇文章中，我们详细介绍了Padis平台的基本概念、架构及其在平安内部的应用。作为一款基于Docker的分布式平台，Padis充分体现了容器技术的优势，为我国平安集团的业务发展提供了有力支持。接下来，我们将进一步阐述Padis平台在实际应用中的优势和价值，以及未来发展趋势。
首先，Padis平台在提高开发效率方面具有显著优势。通过Docker容器技术，开发人员可以轻松地将应用程序打包、分发和部署，大大缩短了软件开发的周期。此外，Docker的跨平台特性使得开发人员在不同环境中都能轻松实现应用程序的迁移，降低了开发和维护成本。
其次，Padis平台在扩展性和可维护性方面表现出色。基于Mesos+Marathon框架，Padis可以实现资源的统一管理和调度，确保应用程序在分布式环境下的高性能和稳定性。同时，Docker容器技术的动态扩缩容特性使得系统能够根据实际负载自动调整资源分配，有效应对业务高峰期，提高了系统的容错能力和负载能力。
除此之外，Padis平台还具备高度的安全性。Docker容器之间的隔离特性确保了应用程序之间的安全性，防止潜在的安全风险传播。同时，通过对容器镜像的严格管理，可以确保应用程序在运行过程中不受外部恶意攻击的影响，提高了整个系统的安全性。
展望未来，随着云计算、大数据和人工智能等技术的发展，Padis平台有望进一步发挥其优势，为平安集团乃至整个行业提供更加高效、智能的计算服务。在平安内部，Padis平台将继续深化与各业务线的合作，助力业务快速发展。同时，平安也将积极探索与其他行业领域的合作机会，将Padis平台的成功经验推广至更多企业，共同推动行业的创新与发展。
总之，Padis平台作为一款基于Docker的分布式平台，已经在实际应用中展现了强大的优势。在未来，随着技术的不断进步和行业需求的日益多样化，Padis平台将继续发挥其独特优势，为平安集团及更多企业提供高性能、高可用、高安全的计算服务，助力业务的快速发展和创新。
在全球架构师峰会七牛云（中国互联网技术联盟成员）专场上，平安科技王耀武分享了在传统金融企业“互联网+”过程中应用docker的实践案例。分享基于docker的容器云-padis解决平安传统的应用交付耗时长、中间件标准化的问题展开。结合不久前联盟发出的“互联网+”技术体系（下图），可以给金融行业技术升级转型提供有力的参考。
目前市面上基于容器云的产品有很多，对于平安而言，则是基于 Docker 的 Padis 平台。所谓 Padis，全称是 PingAn Distribution ——平安分布式平台。Padis 基于 Docker，实现了平安内部的一个分布式平台。它的实现采用了 Mesos+Marathon（下面简称MM） 框架，可以完成应用程序的快速创建、运行、快速缩容扩容以及故障自愈的功能；平台上实现了独立 IP，可以实现任何集群与外部的或者传统的 IP 的通讯；平台负载均衡的方式很多，可以根据容器的动态变化（容器的增删）做动态调整；平台内还有独立的域名解析，可以做到 CMDB 和性能监控的动态更新。
Padis 的「成长」主要历经以下几个阶段：
开发环境 Docker 单机版
测试环境 Padis 上线
生产环境 Padis 上线
Padis 承接平安金管家（原平安人寿App） 系统群
下面是对每个阶段的详细叙述。
开发环境 Docker 单机版
平安传统的交付过程耗时很长。从需求发起，到资源申请，到中间件交互，这些过程往返很多，会耗费大量的人力和时间。而交付流程长，人力支配不足等原因，会导致交付质量的下降。为了解决交付所面临的这一系列难题，Docker 就成为了一种最初的尝试方式。Docker 包含三方面内容（图 1）：仓库、镜像、容器。仓库这方面需要改进的不多，重点放在镜像上面。 2014 年单机版的 Docker 上线，第一版的 Padis 将 Docker 镜像集成到 OS。
针对 LB 的这 几种情况，平安提出了三套方案：
软件负载均衡 HAProxy
基于容器，在容器上面搭建一个 HAProxy。
优点：可以实现基本功能、新版的可以做应用路由（可以根据不同规则，向不同应用上分发路由）、动态更新配置（通过 API 更改配置文件然后进行 Reload）。
缺点：高并发能力比较弱、SSL 卸载能力差。
软件负载均衡 Lvs＋Nginx
LVS+Ospf 调度机自由伸缩，自由扩展（最大 8 台，受限于网络设备允许的等价路由数目）；一个 LVS 后端可以搭建多个 Nginx。
优点：并发能力比较高、可以很轻易的完成动态配置更新、SSL 卸载能力好（ LVS 可以搭建多个 Nginx，Nginx 多了，卸载能力自然有所提升）。
缺点：后端 Nginx 发生频繁变化时（例如由 10 个变成 20 个），当进行等价路由算法时，此时便会发生路由抖动。
硬件负载均衡 LTM
做了自动化配置开发、做了动态接口配置。
缺点：本身扩展能力不好、成本高。
第一版的 Padis 出来时，着手的重点就是定制化的镜像。平安的业务系统非常多，中间件用的东西又比较标准化，所以定制化的主要方向就是标准的中间件怎么去配，才能放到镜像里形成一个标准的东西，这个问题解决了，那么当开发环境的镜像可用时，该镜像放入生产后依旧可用。此时，将应用包或中间件打包起来后就可以快速启动服务；如果要对这个环境进行复制，将原来环境进行拷贝就可以。这样一来，交付就可以做到分钟级别或者是秒级别。
但是，怎么将中间件打到标准镜像中，这又是一个问题。一个容器是有限制的，如果什么东西都打进去，日志会越写越多，容器容量就会爆，容器默认大小只有 10G。金融行业的日志，它必须要落地、必须要存储，有一些需要排查的问题如果没有日志就会很不方便，因此日志一定要保留。而把应用都打到里面去，开始时不会出现太大的问题，但是随着第一个版本的发行，就出现一个让人很不爽的问题：要对镜像作调整，可是无需对应用的独立镜像进行更新。所以必须要将应用包和日志全部挪走，只留下 OS 和 中间件固定配置和介质，才可行。
因为需要根据一些用户需求做调整，所以这个版本的 Padis 出来后在平安内部做了推广并进行反馈收集。对所收集的信息进行整合，发现单机版的 Docker 存在很多缺陷：一是没有集群，不能解决跨 Host 之间的通讯功能；二是没有健康检查机制，容器应用故障无法自愈；三是没有监控和统计信息，资源使用不可控；四是熟悉 Docker 命令的人不多，要去推广使用很困难。公司中各种不同部门的人很多，每个部门的关注重点不一样，当一个部门里的人根本不了解这是什么的时候，是没有办法使用 Docker 的，因此必须做到界面化。所以后续又做了相应的调整，对于用户一定要镜像透明，并把 Docker 做成集群模式。
对于集群模式的选择则做了两个选项，下面先简单介绍一下这两种框架选项。