物理视图
物理视图主要描述平台自身子系统的部署结构以及约束不同类型的业务组件的目录结构。
概述
这是一个比较粗的物理视图，主要是描述技术平台和业务平台在物理上的关系。技术平台本身在部署架构上分为主管节点、应用节点、数据库节点以及监控节点。通过应用节点可以管理不同的用于支撑业务平台运行的环境：Kubernetes（容器集群）和OpenStack（虚拟机集群）。
- 主管节点： 主要负责维护领域系统的部署信息以及领域系统的调度、资源分配等。
- 应用节点： 在其上部署的是运行平台自身的各领域系统。
- 数据库节点： 在其上部署的是运行各领域系统依赖的数据库。
- 监控节点： 在其上部署的是运行监控相关的领域系统，监控目标包括技术平台其它领域系统以及业务平台的组件。
技术平台的部署结构
这张图主要是描述平台自身的部署结构，说明在不同的节点会有些什么服务（进程）。因为领域系统以及其所依赖的服务会要求尽量以镜像作为发布介质，所以选一个容器管理系统会相对方便于我们部署。我们现在选择的是用Kubernetes作为部署底层支撑系统，K8s可以实现领域系统以及其所依赖服务的高可用、负载均衡，当然这个支撑系统是可以替换的：
- 主管节点
- 节点使用集群方式部署，采用3节点组成的一个集群。
- 节点上会部署etcd、kube-apiserver、kube-controller-manager、kube-scheduler。这些程序是作为systemd的服务启动。主要负责领域系统的部署、高可用以及负载均衡。
- 应用节点
- 数据库节点
- 节点可以使用单节点或集群方式部署，推荐使用3个节点。
- 节点上会部署容器调度与监控相关的程序。这些程序是作为systemd的服务启动。
- 节点上会部署各领域系统所需要的数据库。数据库是作为容器启动。
- 监控节点
- 节点可以使用单节点或集群方式部署，推荐使用3个节点。
- 节点上会部署容器调度与监控相关的程序。这些程序是作为systemd的服务启动。
- 节点上会部署监控相关的程序UMC、FTS、heapster、fluentd、influxdb、es，这些程序是用来监控其他领域系统的资源使用以及收集分析其他领域系统的运行日志。这些程序中UMC、FTS、heapster是作为容器启动，其他是作为systemd的服务启动。
- 其它节点
- 其它节点使用单节点方式部署。
- 节点上会部署git-lab、docker-registry、jenkins，这些程序是作为systemd的服务启动。
组件的目录结构
这张图主要是描述组件的目录结构，关于组件的描述可以参见[术语定义-组件]以及技术平台[开发视图]中的相关描述。在物理视图中将组件分成3类，这些组件都会被打成镜像，这里描述的是镜像内的目录结构，这些组件会有一些相同的目录或文件：
- app/conf/autoconfig.properties： 用于存放在启动容器时通过环境变量传入到容器的k-v键值对。
- app/conf/application.yaml： 用于存放应用启动时需要使用的配置。
- app/bin/entrypoint.sh： 容器启动时执行的命令。
- app/bin/autoconfig.sh： 用于将autoconfig.properties值替换到application.yaml中placeholders的位置。
- data： 是一个支持通过容器外部挂载目录，可以用于存放一些需要持久化的信息。
不同类型的组件的差别：
- 后端服务组件： 这种组件不包含页面，只包括业务逻辑以及相应业务模型对象，对外是通过RestAPI暴露服务。整个组件只有一个jar包（application.jar），组件本身的jar以及所依赖的jar都被打到这个application.jar中。
- 前端服务组件： 这种组件只包含静态页面、图片、js等资源，这种组件运行依赖于nginx，所以在conf目录下还会有些nginx相关配置。
- JEE组件： 这种组件既包含业务逻辑也包含页面，可以理解它是一个war，可以看到app的目录结构和tomcat是一样的，组件本身的程序放在了webapps/ROOT下。