项目成员角色可以分为项目司理、产品司理、开辟司理、测试司理。
l 项目司理为整个项目的核心，推动项目的整个举行，包管项目的交付。
l 产品司理主要负责设计项目需求，需求必须符合客户的需要。
l 开辟司理主要举行软件设计以及代码实现，顺遂的实现项目的要求。
l 测试司理主要负责对项目的质量举行审查，确保项目质量达到预期目标。 1.4 项目流程介绍
Microsoft Office Word是微软公司的一个文字处置处罚器应用程序。Word给用户提供了用于创建专业而优雅的文档工具，帮助用户节省时间，并得到优雅美观的效果。不绝以来，Microsoft Office Word都是最盛行的文字处置处罚程序。
作为Office套件的核心程序，Word提供了许多易于利用的文档创建工具，同时也提供了丰富的功能集供创建复杂的文档利用。哪怕只利用Word应用一点文本格式化操纵或图片处置处罚，也可以使简朴的文档变得比只利用纯文本更具吸引力。
该软件可以在网上自行下载安装，下面以Microsoft Office Word 2010版本为例，如图1-5-1所示：
图1-5-1 Microsoft Office Word 2010版本
Word下载安装好后，双击打开该应用程序，打开后的界面如图1-5-2所示，会新建一个word文档。
① Microsoft Office Excel
Microsoft Excel是Microsoft为利用Windows和Apple Macintosh操纵体系的电脑编写的一款电子表格软件。直观的界面、出色的计算功能和图表工具，再加上成功的市场营销，使Excel成为最盛行的个人计算机数据处置处罚软件。
该软件可以自行网上下载，下面以Microsoft Office Excel 2010版本为例，如图1-5-10所示，下载安装好后，桌面上双击打开该应用程序。
图1-5-10 Microsoft Office Excel 2010版本
打开程序后，会新建一个空白的电子表格文件，如图1-5-11所示。
产品司理A来组织产品职员A对客户的需求举行分析，终极形成项目需求。
某银行上云体系所涉及到有需求点有如下：
①银行建立容器平台，不光需要为基于微服务架构的新业务提供容器化运行和管控平台之外，还必须非常重视满意金融行业严苛的监管和安全要求。这样的定位决定了在银行建立容器平台除了要具备市场上大多数容器平台产品的能力，还应该为银行的特殊监管需求举行定制。
②因此订定银行容器平台的需求时，发起思量包罗的方面有：
l 管理大规模容器集群能力，包罗：提供容器所需的高可用集群、资源池管理、网络通信方案、存储方案、编排调度引擎、微服务运行框架、镜像管理、事件告警、集群监控和日记收集等。
l 为满意金融业务的监管和安全要求，平台需要思量应用的高可用性和业务一连性、多租户安全隔离、不划一级业务隔离、防火墙策略、安全漏洞扫描、镜像安全、背景运维的4A纳管、审计日记；如果容器平台还对公网提供访问，那么还需要思量访问链路加密、安全证书等。
③还有一个重要方面是，银行的金融云是一个范围更大的复杂云情况，容器平台通常是这个复杂体系中的一部门，因此容器平台还要遵从银行已有IT技术规范和运维要求，比方可能还需要思量：
l 支持银行自身的应用发布体系、持续集成体系、应用建模规范、高可用管理策略。
l 对接金融云底层资源池（比方IaaS），遵从云计算资源的统一管理和分配。
l 对接或改造容器平台的网络，以满意容器平台中应用与传统虚拟机、物理机中旧业务体系的相互通信，制止或尽可能淘汰对银行现有网络管理模式的打击。
l 对接统一身份验证、和整个金融云别的体系采用统一的租户界说、角色界说、资源配额界说等。
l 对接漏洞扫描、集中监控体系、日记分析体系等已有周边体系。
（2）订定项目需求
开辟司理A召集开辟职员A，开辟职员B根据体系需求举行体系概要设计。
① 体系架构设计
基于对容器平台的需求分析，可以用如图1-5-21所描述的容器平台应用提供的业务能力、以及容器平台在银行可能和周边体系的对接关系：
图1-5-21 业务架构图
如图1-5-22所示为体系构架图：
图1-5-22 体系构架图
（2）体系详细设计
开辟司理A召集开辟职员A，开辟职员B根据体系需求以及体系概要设计举行体系详细设计。
1）资源池管理
容器平台资源池管理负责容器运行所需的计算、存储资源申请、分配、容量管理，以及恰当的容器网络通信方案。
对于计算和存储资源的申请、分配、容量管理，可能的两种做法是：
按照容量预估，预先为容器平台分配预测的计算节点、存储容量的资源，在容器平台中将这些资源注册到容器集群中利用。当需要扩容或删除某些资源时，重复相应的动作。
对接外部的资源管理和供给体系，通常是IaaS体系或者具备资源供给能力的主动化体系，通过调用外部体系的接口，容器平台按需获取所需的计算和存储资源。
2）网络设计
在资源管理中，网络的管理是比较复杂的。对于容器平台可能的网络方案，基本上分为以下几类：
l 原生NAT方案。
l 隧道方案（Overlay），代表性的方案有Flannel、Docker Overlay、OVS等。
l 路由方案，代表性的方案有Calico、MacVlan。
l 自界说网络方案。
原生NAT方案中，容器借助宿主机端口映射、以及在宿主机上设置的iptables规则，对容器的网络数据包举行NAT转换，再通过宿主机的路由转发实现不同容器间跨主机的网络通信。这种方式的优势是原生支持、简朴、容器实例不需要额外消耗骨干网络IP地点、也不会增加在宿主机间传递数据包的长度；但是缺陷也是显着的：
l 同一宿主机上不同容器在宿主机上的映射端口必须区分开以制止端口辩论；
l 容器迁移到不同宿主机时，很可能需要改变所映射的宿主机端口，控制比较麻烦；
l 通过NAT通信使得容器网络数据包在骨干网上利用的不是自身的IP，给防火墙策略带来不便；
l 端口映射带来的网络性能损失，笔者本身的情况下测试效果是，利用NAT方式的容器在举行跨宿主机通信是，吞吐率只能达到宿主机间吞吐率的1/3。
因此，原生的NAT网络比较恰当小规模的功能验证和试验情况，网络性能不是重要的思量因素，测试的场景中也不涉及很多容器迁移、防火墙安全等问题。很显然，在银行正式的测试情况、生产情况下，采用原生NAT方案不敷以满意功能、性能和安全监管要求。
3）网络拓扑规划
除了技术方案，网络拓扑规划是网络设计的另一个重要方面，不光涉及网络管理复杂度，还直接关系到安全合规。传统上银行科技部门会为不同安全等级的应用划分不同的网络区，分别提供不同的安全等级保护；也可能会根据运行业务的特点，分为可直接对外提供服务的网络隔离区，和只在内部运行业务处置处罚和数据处置处罚的业务区、数据库区等。在规划容器平台的网络拓扑时，发起生存这些已经成熟并实践多年的网络地域划分方法，保持服从对安全合规的监管要求。
同时，根据对容器平台的定位和管理策略，容器平台可能需要在传统的网络拓扑上做相应的扩充，比方：
l 如果容器平台是金融云的一部门，网络拓扑必须支持多租户的隔离；
l 容器平台中的容器和宿主机都运行在网络中，容器运行应用属于业务，而宿主机运行容器属于资源，发起把容器地点的业务域和宿主机地点的资源域划分到不同的网络区，分别利用不同的管理和访问策略，生存充足的机动性满意不同的用户需求；
l 容器平台自身运行所需的管理节点、镜像堆栈、计算节点可以思量放到不同的网络区，以满意它们各自不同的运行要求。比方，镜像堆栈可能需要提供对公网的服务，以便用户从公网浏览和管理镜像、管理节点可能需要运行在支持带外管理的网络区等。
如图1-5-23所示总结以上探讨的银行如何规划容器平台网络拓扑的内容：
图1-5-24 镜像堆栈体系和相关工作流程
5）应用管理
应用管理负责运行基于容器镜像的轻量级应用或微服务，提供应用的微服务编排能力、应用全生命周期管理。
6）应用编排
应用编排的目的是为了给容器平台上运行的应用举行建模尺度化，描述应用运行的资源需求、摆设模式、摆设参数、运行时动态规则（弹性伸缩、故障迁移等）。现在开源和商用容器平台都已支持本身的应用编排，比方Kubernetes的yaml文件方式，但对银行来说，可能还存在一些不敷：
l 对银行的特定需求支持不敷，比方银行应用的安全等级、摆设的网路区等这些特殊信息的描述；
l 不同的容器编排体系、甚至同一编排体系的不同版本，可能存在编排语法不同、不兼容的问题。银行的应用建模是重要的资产，不能答应由于版本升级、技术改造而导致众多应用的建模不兼容。
因此发起容器平台自界说应用编排规范，如果容器平台定位为银行整体金融云的一部门，那么容器平台的应用编排应兼容整体金融云的应用建模规范，确保金融云上所有应用建模的一致性。
在用自界说的编排规范对应用举行尺度化描述后，需要对底层的容器平台举行能力扩充定制，对应用编排信息举行翻译，变成容器平台可以理解的信息，再根据这些信息对应用举行摆设、升级和运行管理。
如图1-5-25所示描述了应用建模、以及利用应用建模举行摆设、升级和运行管理的过程。
图1-5-25 应用建模摆设、升级和运行管理的过程
7）生命周期管理
应用全生命周期管理负责应用的上架、摆设、升级、下架、支持运行时动态管理策略，还可支持双活摆设、同城灾备切换等金融云高级能力。这部门功能可能需要对接金融云的应用发布、高可用摆设和切换模块，提供整个金融云所有应用统一的摆设、高可用体验。在上方应用编排，讨论了有关上架、摆设、升级、运行管理等，这里来看应用的高可用摆设和切换。
容器平台可以从实例、服务、应用三个层级，分别实现应用的高可用，分别是：
l 实例级，即容器故障主动恢复；
l 服务级，即服务/微服务的多个实例的跨不同可用区摆设；
l 应用级，即应用跨数据中央切换。
8）安全管理
安全管理是满意行业监管要求必须思量的问题，是银行建立容器平台的特殊要求。
安全管理的难点在于涉及面广，包罗体系漏洞、病毒威胁、链路加密、攻击防范、体系访问权限上收、操纵审计等，别的安全管理面对的安全威胁不断地发展变化，也增加了防范的技术难度和持续的工作量。同时金融云和容器自身的特点，在传统银行安全管理的基础上，还增加了多租户隔离、角色管理、镜像安全检测等新问题。
9）对接安全合规体系
鉴于安全管理的复杂性，如果在容器平台中单独举行安全管理，代价很高；而且安全管理也十分依赖长时间的积累，容器平台单独举行安全管理，也不免在一段时间内出现各种安全问题纰漏。因此发起容器平台在安全管理上直接对接银行现有的安全管理防范体系，充分利用现有的各类安全工具、本领，在现有安全管理本领的基础上，按需增加功能应对容器平台带来的新需求新问题。这应该是见效快、本钱低、风险也比较低的方式。
10）多租户隔离
如果容器平台作为金融云的一部门，并筹划为不同的租户提供服务，那么根据租户对安全的要求，支持不同租户的隔离也是要思量的内容。
在之前讨论网络拓扑规划时，发起把不同租户的容器运行在各自不同的虚拟网络VLAN中，并为不同的VLAN设置必须的防火墙规则、关闭相关的路由来包管不同租户的业务在网络上隔离。
由于容器共享宿主机内核的特点，如果把不同租户的容器运行在同一台宿主机上，租户可能面对来自其他租户容器运行带来的倒霉影响，比方：
l 资源竞争导致的性能下降；
l 其他租户容器应用的bug导致的宿主机内核运行异常，进而导致本身租户容器的运行故障；
l 潜在的来自其他租户的恶意容器应用，利用共享内核举行攻击和窃密。
因此，发起容器平台为不同的租户分配各自专属的、不同的资源池，租户只能在属于本身的宿主机上运行本身的容器应用。这固然导致了资源利用率的低沉，但在根本上回避了容器运行依赖共享宿主机内核、隔离性天生不如虚拟机的局限，这和主要基于虚拟机的IaaS平台对多租户隔离的做法不同。
11）应用等级隔离
除了不同租户间的隔离，纵然在同一租户下，运行不同安全等级的应用，因为容器共享体系内核的特点，应用也面对别的等级应用的资源争抢、故障影响等问题。别的，不划一级的应用，往往要求不同级别的运行情况高可用性、安全性，因此在同一租户下，也应该把不划一级的应用隔离开，分别摆设到各自专属的资源池内。
如图1-5-26所示以两个租户、分别有不同的安全等级的应用摆设为例，描绘应用的摆设状态：
图1-5-26 应用摆设状态
12）监控日记
①监控
和安全管理类似，监控体系也在银行发展多年，特别是针对生产体系的监控、告警体系，根据自身运维的需要，不断积累、优化了多年，大多已经比较完备；围绕现在的监控体系，也形成了成熟的应急方案、流程，职员技能和经验也多围绕既有生产监控体系举行培训、学习。
因此，如果容器平台没有特别的需求，在银行的生产情况下，发起将容器平台的监控体系对接现在的集中监控体系，方便运维职员对生产情况的统一监控管理，既有的应急方案、流程、职员技能和经验都可以得到沿用。
在设计详细的监控时，应把监控举行分类，分别处置处罚。详细可分为：
l 应用和服务监控
l 资源监控
l 平台监控
应用和服务监控关心业务服务的正确工作状态，这可能需要通过调用平台API、或通过应用日记分析、特定端口相应等方法来判定，需要开辟一定的逻辑处置处罚，再把效果对接到集中监控。
资源监控主要关注每个宿主机、以及计算节点集群的整体资源的利用情况，是否需要增加节点扩容等，这一点基本上传统的监控体系都已经能够做到，方式上以在宿主机上运行agent，举行资源数据收集、然后上报为多。
平台的监控关注容器平台的控制节点、数据库、提供的服务等是否工作正常，这一点通常开源和商业的容器平台自身就已提供相应的管理控制台。如果不介怀界面风格的差异，集中监控体系可以直接嵌入或跳转到容器平台的管理控制台；如果为了一致的监控体验，或者需要进一步的监控和告警定制，就需要开辟集成逻辑，通过调用容器平台的API，对获得的数据举行处置处罚、封装，再对接到集中监控体系。
②日记
在容器平台中，日记大致分为两类：
l 情况日记，包罗容器运行日记、宿主机容器引擎日记、容器平台管理日记；
l 应用日记，指运行在容器中的业务应用在举行业务处置处罚中，对处置处罚过程中的关键效果、状态所举行的记录。
情况日记有各自固定的输出位置，主要用于出现故障时举行运维排查，和容器平台运行的业务并无直接关系；对于容器平台，更需要关注、处置处罚的是应用日记。因为以容器为载体，以分布式方式运行，无论是运行位置、数量等都会随时发生变化，所以如果不对应用日记做特别处置处罚，应用日记会散布在容器集群的恣意节点上。传统的方式，即登录到某一个特定的节点上去查看日记，已经不能实用于容器平台中的应用了。
用户必须对应用的日记举行集中收集，相关的开源方案选择也比较丰富，比方ELK、Fluentd等，或者直接通过在容器中挂载NFS共享文件体系，把业务运行的日记实时写到共享文件体系中举行集中收集。
13）PaaS数据框架
PaaS数据框架如图1-5-27所示：
图1-5-28实现集群主动扩容
l 容器平台主动发送扩容工作单到服务流程平台，审批通事后，调用IaaS平台主动按照容器平台尺度模板创建虚拟机。
l IaaS平台负责交付容器虚拟机、基础设置和安全检查，并开通该虚拟机到容器平台的网络访问控制，完成后更新设置库并关照容器平台。
l 容器平台收到虚拟机设置信息后，主动完成负责均衡节点或计算节点的集群加入工作。
目标：容器集群采用预制原则，保持利用率在70%以下，当容量不敷时主动触发扩容流程，完成集群资源扩容工作。
15）集群扩容
集群扩容如图1-5-29所示：
图1-5-29 集群扩容
16）监控、告警
监控、告警如图1-5-30所示：
图1-5-30监控、告警
（3）体系设计工具介绍（Microsoft Office Visio）
Microsoft Office Visio是office软件系列中的负责绘制流程图和表示图的软件，是一款便于IT和商务职员就复杂信息、体系和流程举行可视化处置处罚、分析和交换的软件。
以Microsoft Office Visio 2010版本为例，如图1-5-31所示，请自行下载安装包，下载完成后举行安装好，在桌面上双击该图标，打开程序。
图1-5-31 Microsoft Office Visio 2010版本
①打开Visio 2010后的首界面，如图1-5-32所示，可以单击“新建”按钮，选择基础模板或者空白模板。
测试实行，根据测试用例的详细步骤，实行用例，并将实行效果记录和问题记录。
软件测试阶段的工作就是根据需求设计的测试方案和测试用例，利用人工或测试工具对产品举行功能和非功能测试，需要跟踪故障缺陷，以确保开辟的产品恰当需求。测试职员在这个阶段需要准备测试陈诉，终极总结出体系测试评审陈诉。
测试阶段需要测试职员来主导，开辟职员共同修改缺陷，以确保产品格量。这里的测试主要包罗代码扫描、功能测试、性能测试、安全测试和回归测试。
测试职员在设计和实行测试用例时，需要秉承如下几个重要原则：
l 测试用例需清晰界说对预期的输入和输出；
l 应当彻底检查每个测试的实行效果；
l 测试用例的编写不光应当根据有用和预推测的输入情况，而且也应当思量无效和未预推测的输入情况。
《测试陈诉》测试工作完成以后，应提交测试筹划实行情况的说明，对测试效果加以分析，并提出测试的结论意见。见附录8《测试陈诉》。 7.项目上线结项
