|
@eximbank 某金融企业 系统架构师： 1、得看看本企业内容的成员技术实力，若是没有技术储备，那就瞄准大厂的服务即可，若有技术储备，那么要确信容器云平台建设是一个循序渐进的探索和适应过程。 2、试试某业务系统下，双形态运行（传统架构 Docker架构）运行探索。有了一定的运行经验后，技术储备就可以展开。这个过程，可能就是不去改造业务系统，仅仅是Docker架构运行，可以验证技术储备和团队的驾驭能力。 3、容器云其实更多的技术储备是关注基础，经验是首先解决团队的网络技术储备人员，如果这个技术储备解决了，基本上大的问题就解决了至少70%。如果没有网络技术储备的话，不建议为了容器云而容器云平台建设。 4、有了网络技术储备，存储储备相对来说不是特别困难，也需要相应的技术投入。 5、最后的各种平台就自行探索，学习和试错成本理论上都不会太巨大。 6、如果涉及的业务应用改造，建议先易后难、先外围后核心、先不重要再重要的探索。 7、涉及应用就一定会涉及 CI/CD 及相关的工具链平台，学习、试错和技术储备先从开发、测试开始进行探索，不建议直接上上生产环境。建议先独立掌握各个工具链后再做企业化改造和集成统一，否则会吃大亏。 8、各个开源及工具链，要成为企业平台，期间有很多路和坑是需要不停的升级提升技术、实践经验等。 9、入场思路有两个思路。 1）找个大厂，小项目学习，提升技术和经验，当然看看组织内的助力和阻力在什么地方？成本不宜过大。抱着失败的状态来交付，但一定要有技术学习、技术经验积累等收获，不能什么都没有，那就真的失败了；之后，owner就会明白该怎么落实。 2）组阁团队，先自行从开源工具链、业务应用开发、容器本身运营和运维想结合试错学习和积累，之后再同各大厂商交流、同业交流，一定要到参考案例的客户那里去探到真实的情况，别信国内厂商的夸夸其谈，否则人家卖了自己都还不知道怎么回事。 10、多说一句，一定要有领导的支持，别因为这个给自己留下不好的印象，这就不值当～～～本来是一股激情冲劲想做弄潮儿，结果变成了被炒对象，那就不值当。 @Steven99 软件架构设计师： 这是一个长期的过程，需要分阶段实施，几句话很难说清楚。 第一，可能需要邀请厂商进行深入交流，到同行去考察交流，对自己企业的情况和需求有个相对合理的认知，规模和成本基于实际的需求，厂商产品，以及实现方式，差别还是挺大。 第二，基于调查研究的基础上规划容器云，DevOps，云管，资源管理，微服务，应用管理，服务治理，API管理，日志，监控，配置管理等的角色地位和实施步骤。 第三，测算投入及里程碑产出，就是分阶段实施步骤及人员，资金投入计划，风险管控。 第四，具体实施，这个比较难，厂商能力差别大，产品更是没有标准，需要自身极大的投入和管控能力，否则很可能实施个玩具，漏洞百出，建议不要相信厂商说的，如果可能让两厂商竞争，谁胜出谁拿钱，甚至双份的钱。 第五，具体的技术细节问题坑就很多了，但最重要的是保证整体的架构，框架是合理的，分布式，可扩展，稳定，高可用等。 第六，通常首期不建议大投入，先期试水，也考察厂商，不合适立马换掉，否则这才是最大的坑。首期百八十万就足够了。 第七，首选产品相对成熟的，什么都敢承诺往往什么都做不好，合同要明确约定，选择适合的产品。 @lyc19820 软件开发工程师： 单从技术角度看，容器云平台的核心主要包括容器、服务编排和网络等内容，企业级平台的建设思路一般是以这些功能为核心，进行各种企业级功能的建设和完善： 1） 容器：目前主流的有Docker，Garden和Rocket等，关注度最高的是Docker（分为社区版CE和企业版EE）；Garden是Cloud Foundry支持的容器;；Rocket是CoreOS推出的容器技术。Docker和Garden都有实际的金融业应用。容器技术现在已经成为一种行业标准，选择时可选择参考行业标准制定的成员单位、贡献度和话语权等；在互联网公司，阿里、腾讯、百度、网易、京东和华为的内部平台建设或者对外商用产品发布均采用了docker技术，可见docker有更加广泛的用户群体。 2） 服务编排：服务编排框架有多种实现形式，目前多数采用kubernets(k8s)，成为一种市场主流选择，k8s是Google内部的大规模集群管理工具开源而来，受到Microsoft、VMWare、Red Hat、CoreOS、Mesos等各大巨头青睐，纷纷为其共享源码。设计宗旨是维护应用容器集群一直处于用户所期望的状态，并且建立一套健壮的集群自恢复机制，包括容器的自动重启、自动调度和自动备份等功能。Swarm是Docker原厂的容器编排引擎，也分为社区版和企业版。在各种调查中可以发现k8s是普及度比较高的。 容器云建设方式的选择： 1）自研：基于选择的容器和服务编排框架为基础进行自研，这种情况对团队的各项技能要求都相对比较高。不推荐。 2）联合开发：与云平台厂商进行联合研发，这种模式一方面可以更好的满足行内各种实际需求，另一方面可以充分利用厂商的专业技术能力，但这种研发没有固定模式可寻，建设周期相对较长； 3）产品购买：购买成熟化的市场产品，这种模式建设周期相对较短，在进行本行落地定制化的过程中一般有应用案例可参考，一般建设周期相对较短，定制研发多以落地为主，技能要求相对较低，选择时建议选择相对开放易于定制的产品。 企业在进行技术路线选择时，需要综合考虑平台的建设目标、投入成本、团队技术储备、所选技术路线的成熟度、生态圈发展情况及其未来发展趋势等多种因素。 容器云的建设有哪些风险需要考虑？ 1） 技术选型的成本：容器云需要优先选择容器和服务编排的技术路线，选定后基本可以确定产品的系统架构，在实施后再进行修改或者更换的成本相对比较大；如果选择的技术路线以后停止更新不发展了，也会面临各种技术支持等问题； 2） 开源框架快速发展：目前主流的编排技术（如K8S）均为开源软件，随着容器云技术在企业中越来越多的普及应用，开源软件自我完善和发展的速度比较快，版本更迭频繁，甚至不同版本之间架构等差异比较大。因此需要更加关注软件生命周期过程中框架的平滑升级和过渡； 3） 应用高可用的风险：从架构层面看，容器云是一个整体，容器云内部架构出现异常，可能会导致整个云异常，影响容器云上的所有应用。因此，高可用、可靠性需要反复测试演练，并形成灾难恢复应急文档； 4） 在企业内部落地的风险：容器云上运行的是证券业务系统，因此必须遵循证券系统的特点，比如满足应用系统安保等级要求等，容器云的落地，一方面是技术方面的风险，比如和公司现有各种现有系统的对接等；一方面是制度流程方面的风险，容器云必然会带来很多新的思维和理念，这些最终需要靠制度流程来保证实施，需要进行流程梳理和修改，避免“水土不服”。 容器云建设时需要考虑哪些难点和重点？ 容器云建设是一个复杂的系统化工程，每家企业容器云建设的出发点、设计目标各不相同，因此建设的内容会存在差异，但主要的建设难点或者重点包括但不限于如下内容： 1）与基础设施的融合：容器云与基础设备的关系如何定位，容器云平台的管理内容包不包含底层vmware、openstack或者物理机； 2）网络建设：容器云中大量容器需要进行网络隔离或者网络连通，网络连通时使用哪种网络设施，诸如vxlan的overlay、平网络还是基础设备的underlay（IaaS的网络），不同的选择在网络性能、网络节点规模等方面各不相同； 3） 存储：对在容器中需要使用存储的容器而言，存储设施存在多种选型方案，比如采用ceph、NAS或者glusterfs等； 4）日志：运行在容器云的应用集群，如何进行日志管理，是采用EFK还是对接行内统一日志管理系统； 5） 监控：容器云上的应用如何进行监控，是单独采用云产品的自有监控体系，还是对接单位内部已有监控系统； 6） 中间件集成：容器云适合集成哪些中间件服务（比如数据库、缓存等），集成中间件之后，中间件中保存的数据如何进行处理，中间件的管理和运维如何进行？ 容器云平台既要于底层基础设施交互，又要支持顶层应用，涉及面和覆盖面都非常广，因此建设过程中与单位内部已有设备、流程等进行结合时需要进行综合考虑，上述内容仅作抛砖引玉的参考，在不断的交流中让大家不断进步，一起成长，从而将单位的容器云建设的更加有效，更加高效。（部分观点引自社区活动中同行分享，可参考：银行业容器云平台建设的三个W） @yeefone 某大型保险公司 技术经理： 容器云落地应注意上云的业务是哪些，遵循先易后难原则，先上无状态应用，还要考虑原有微服务的架构是否要调整，比如springcloud框架的很多组件(服务发现、注册中心等)和k8s是有重叠的； 关于容器云的技术底座，随着k8s技术和产品的逐渐成熟，可选择的产品很多；可以考虑多集群模式，充分利用公司已有的IaaS平台的能力； 关于建设路线，不要试图一开始上一个大而全的平台，涵盖k8s底座 微服务框架 devops，应该分层建设，这样成本和目标都比较清晰可控。 @某金融企业 技术经理： 需要结合自身的能力和需求进行评估。几个问题在开始项目前可以先定下来。 1、自建，合作开发还是现成产品。自建的难度很大，坑太多，不建议。如果技术能力可以，后续希望能够做大的扩展，合作开发是个选择。如果想要快速搭建，找个厂商的商用产品。成本这个强相关。 2、平台的范围，如DevOps，统一监控是要新建还是对接。 3、应用是否已经准备好了，容器化的优势要发挥出来，需要应用进行改造。 @泊涯 测试技术专家： 对于开发来说或许会更好，更敏捷吧。 但是如果使用开源的在运维技术上，高可用性、可靠性方面还是建议在测试环境试运行一小段时间，包含性能测试、可靠性测试和持续性集成部署等带来的空间问题还是要注意。 @shendb 某大型保险 技术经理： 从几个方面阐述一下个人的几点认识。 1、容器技术发展到今天，应该可以认为是一个成熟的技术。就容器技术本身来说，小问题肯定还是会在很长一段时期内存在，但总的来说还是比较可靠的。 2、要引入容器技术首先需要明确企业后续对容器的定位，比如：是在小范围创新应用使用还是准备全面推广、是面向高级技术人员还是面向普通应用用户、企业对应用可用性及业务连续性 要求等方面都决定了后续在容器平台建设过程中的投入，包括人员、软件开发、硬件的投入。 3、建议先做一个较完整的POC，重点可放在企业流程的适应性、应用的适配性、生产的可维护性方面，然后再来考虑容器平台的建设策略及对应的投入。 这些问题的每一个，都会导致投入的差异。所以建立在这些问题基本确认后再一起探讨投入和问题会比较合适。 @chinesezzqiang 信息技术经理： 若构建容器云，有以下几点建议： 1、明确业务需求，就是说你为什么构建容器云，要达成什么目的。比如希望通过容器云实现DevOps，达到敏捷开发的目的，还是用于构建产品测试环境，或者学习使用。（建议不要上来就搞生产环境） 2、选型，选择什么样的技术平台来构建容器云。比如选择开源还是闭源，通过优劣势对比，确定平台方向。 3、企业自身技术储备，要评估企业自身是否具备容器云技术的驾驭能力，需要系统、网络、容器、存储存等人才，利于后期的故障排查，加固扩展，系统优化等。 4、明确哪些业务上云，不是所有的业务都适合跑在容器云中，比如重量级的系统就不适合，如ERP，SRM。一些toc的应用还是可以上云的，如官网、电商平台等，切记不要为了上云而上云，业务稳定是第一准则。 5、上云节奏的把控，系统上云是一个循序渐进的探索和适应过程，不要因快而造成业务影响。要先易后难，先toc后tob。 6、平台运营，建议找个有实力的供应商进行部署，期间形成各种手册、标准、培训和流程。项目期间，不断学习和试错，确保后期运营稳定。 7、循序渐近，无论在平台扩展还是技术学习，都要循序渐进，欲速则不达。项目中遇到的坑要及时解决，防止为后期留下隐患。 8、开放心态，要多组织学习，与同行多沟通，多学习，不要固步自封。 9、匹配企业发展规划，所有的技术架构都服务于企业架构，一定要匹配企业的发展需要，切勿盲目创新。 |
|
|
