电信行业 BSS/OSS 基于 OpenShift 实现容器化改造实践分享
以下内容分为四个方面：
1、容器运维监控
2、BSS/OSS应用迁移改造
3、容器如何保证业务连续性
4、容器化开发和技能
5、BSS/OSS应用容器化方案评估
一、容器运维监控
1、OpenShift中关于系统运维中故障管理有哪些方法和手段?
【问题描述】容器化以后，我的理解就拆分成了三层：硬件层、容器层、应用层。各个层如何做横向以及性能管理和故障发现有哪些快速定位手段? 纵向的跨层故障关联如何实现?
@沈卫忠 红帽高级方案架构师：
就OpenShift容器云平台而言，监控是采用了普罗米修斯和Grafana进行系统监控的。
每个节点上都运行一个Node-Exporter的进程，负责监测主机节点的CPU使用率，CPU负载，内存使用率，磁盘空间使用率，磁盘I/O，网络流量，系统进程数等；
同时节点上另一个进程Kube-state-metrics负责获取Kubernetes对象相关信息，比如pod的CPU使用率，CPU负载，内存使用等；
1. 普罗米修斯通过HTTP采取上述两个进程暴露的信息，存放到时序数据库中去，而 Grafana 负责显示监控信息。2. 普罗米修斯和Grafana 本身已经内置对硬件和容器的监控，我们也可以扩展增加对应用的监控。3. 普罗米修斯AlertManager可以根据获取的指标信息发起web hook请求，从而达到自动通知目的（可与已有告警系统集成） 4. 如果底层的硬件坏了比如服务器彻底坏了，openshift能够重新调度所有的Pod到其他节点。如果部分硬件坏掉，OpenShift也可以根据资源使用状况调度一些pod去其他节点。5. pod如果崩溃或死掉，OpenShift/K8S的LivenessProbe会失败，从而创建pod. 6. 应用本身的日志应该用EFK统一管理，可以帮助故障分析。
2、容器化中有哪些工具辅助监控系统或硬件性能？
@朱祥磊 某移动公司 系统架构师：
cAdvisor+Influxdb+Grafana是一套为容器集群性能监控设计的开源解决方案，利用cAdvisor 对容器信息的良好监控能力，Influxdb对时间序列数据的快速检索能力，以及Grafana的强大图标展示能力，形成性能数据的实时查看和历史回溯。日志管理方面，当下最主流的容器日志开源工具组合ELK，或者EFK。另外还有prometheus+alertmanager可以实现短信或者发邮件下发告警。总之，容器生态圈有很多的监控工具，客户可以结合自己的业务使用场景，选择自己最适合的工具。
@沈卫忠 红帽高级方案架构师：
就OpenShift容器云平台而言，是采用了普罗米修斯和Grafana进行系统监控的。每个节点上都运行一个Node-Exporter的进程，负责监测主机节点的CPU使用率，CPU负载，内存使用率，磁盘空间使用率，磁盘I/O，网络流量，系统进程数等；同时节点上另一个进程Kube-state-metrics负责获取Kubernetes对象相关信息，比如pod的CPU使用率，CPU负载，内存使用等；普罗米修斯通过HTTP采取上述两个进程暴露的信息，存放到时序数据库中去，而 Grafana 负责显示监控信息。
3、对于容器化故障运维保障有哪些建议？
@朱祥磊 某移动公司 系统架构师：
对于容器化故障运维保障，需要做到以下几个方面：
1、对整个集群的状态，做健康检查，目前可以通过prometheus, Grafana监控系统 ,通过prometheus定期抓取指标，设置告警，送到altermanager,altermanager调用短信网关，或者邮件，就可以下发短信，或者邮件告警，这样运维人员可以立马相应处理。
2、对于容器化的应用， 很多的微服务，有问题了，定位问题，需要查看日志，而容器日志多，查看日志就需要借助一个ELK或者EFK一整套的日志解决方案。
3、使用自动化的运维工具，提供工作效率。
4、每个微服务要去除对单个节点的强依赖，这样即使一个节点宕机了，对业务也没有影响。
5、对于重要的节点，如k8s的master节点，要做高可用HA，即使一个节点宕机，对集群也没有影响。
6、镜像仓库也要做高可用。即使一个仓库出问题，根据高可用，使用一个虚拟IP，可以漂移到另外一个节点 ，为k8s集群的镜像拉取提供可靠服务。
@沈卫忠 红帽高级方案架构师：
1. 应该建立一个监控系统，比如就OpenShift容器云平台而言，本身提供了 普罗米修斯和Grafana监控系统，而且普罗米修斯里面的AlertManager也可以通过配置告警规则触发web hooks，跟已有的告警系统集成。
2. 应该建立一个统一日志系统，比如 EFK或ELK日志系统。
3. 如果有统一的自动化运维系统，可以将自动化运维系统对接容器云平台。
二、BSS/OSS应用迁移改造
1、容器云针对传统计费系统的数据库系统如何进行替代？
@eximbank 某金融企业 系统架构师：
1，技术上是完全可以支撑这种替换，但是更多需要是考虑业务计费系统运行要求，是否满足当下监管的规范和安全体系；
2，传统计费系统架构重塑、梳理、分拆，将传统的大而全的紧耦合数据集交付，梳理分拆成适合微服务化的松耦合分布式数据交付；
3，数据库服务与计费系统逻辑处理服务的松耦合，并且由原来同步交互数据集转变到异步交换同步数据集，也就是由集中统一交付变成松耦合分布式交付，只要确保每一个为服务负责的数据正确，数据链路不中断即可；
4，数据库本身是为业务应用所用，数据库本身被替换并不是存在技术瓶颈，真正的瓶颈是业务-应用系统的要求；尤其很多计费系统不管是业务本身属性有要求，对于监管机构也有要求，这些因素往往是改造和升级的瓶颈，所以梳理和分析这些因素是极其重要的步骤，而且是不够可逾越的步骤。
@朱祥磊 某移动公司 系统架构师：
计费系统数据库数据量巨大、频繁增改，属于IO密集型，并不建议容器化，但对计费应用来说是可以容器化的。可以考虑内存库替代传统数据库。
@沈卫忠 红帽高级方案架构师：
1. 在电信支撑的BOSS系统中，计费系统数据库储存着高达几千万的用户数据，海量话单（每天高达几十亿）、帐单帐务数据，因此，是传统BOSS中技术难度最高的，也往往采用了一些例如分库分表的方法来给数据库减量。在BOSS现代化改造中，这一块的改造建议放到最后去做。
2. 但是，某些数据，比如用户数据，包括用户订购产品数据是可以在微服务改造过程随着它们所对应的微服务（比如客户微服务）可以拆出去的。由于拆出去的客户数据库的数据表相对来说比较少（客户相关信息），数据记录相对于话单来说也说的多，对数据库的要求比原来明显降低，替代难度就相对来说不是很高了，可选的数据库的面也比较大啊（当然这个也要考虑IOPS, 查询和更新效率等）。
2、单体巨型BOSS系统，作为电信行业核心系统，未来是否有必要转向基于云计算的BOSS?
@沈卫忠 红帽高级方案架构师：
云计算、云原生、微服务对于企业的引领作用，大家在互联网行业都看到了，这里面就不多说了。既然电信行业已经不再是一个是垄断行业，而且随着改革开放的深入，我们预期市场竞争也会越来越激烈。所以，电信业务支撑系统BOSS势必要转向云原生，我们要关注的重点是如何转，如何在转型过程中减少风险。
当然，对于某些跟网络侧联系紧密，业务比较稳定，不跟客户端发生关系的稳态O域应用，可以不进行转型。
@某电信架构师：
boss系统已完成云化改造，但容器化的步伐相对较慢，主要是业务逻辑太复杂，从技术发展趋势看还是有必要的，特别是业务资费开发的部分。
三、容器如何保证业务连续性
1、如何保障系统容器化改造的过程中业务的连续性？
@朱祥磊 某移动公司 系统架构师：
建议采用新旧系统并存方式，新系统为容器化，逐步将相关业务的消息发到新的系统，实现新旧系统替换。
@沈卫忠 红帽高级方案架构师：
1. OSS系统一般来说分为服务开通，资源管理，网络激活等，中间一般采用异步消息传输机制。
2. 容器化改造一般采用功能逐步替代，由简到难的过程。比如前面提到三个模块，一般而言网络激活最简单，比较容易改造微服务。
3.以网络激活改造微服务为例，由于采用消息机制，我们可以创建一个新的网络激活容器化应用，在消息队列里面路由小部分消息过来逐步上线，最终逐步接管整个网络激活。
4. 其他模块的容器化改造思路类似，利用消息的路由机制控制新旧系统的负载比例。
2、容器云如何实现快速部署及快速恢复？
@沈卫忠 红帽高级方案架构师：
OpenShift从版本4开始推出了快速部署的功能，它的安装模式包括一种IPI(Installer Provisioned Infrastructure)模式，能够支持在裸机、VMWare、 OpenStack和公有云AWS, AZure上同时创建操作系统和OpenShift，基本上是一键式安装，减少了安装复杂度。
四、容器化开发和技能
1、容器化后，传统运维向自动化运维需要具备哪些技能，能更好的支撑？
@朱祥磊 某移动公司 系统架构师：
容器化后，应用都是容器化的，也就是以前直接运行在操作系统之上的单体应用程序，需要根据单体应用架构，拆分为许多微服务，基本上每个微服务都运行在独立的一个容器里面，紧密耦合的微服务，考虑到通信性能，也可以运行在同一个容器里面。通过上面的分析，容器化后，要求运维人员具备docker的诸多知识。还有微服务之间的调度关系， 容器的调度，需要用到容器生态圈里面的容器编排引擎，现在最火的当属kubernetes了。存储镜像使用的镜像仓库，也需要搭建，维护，清理。总之 ，容器化之后，对运维人员提出了新的要求，需要运维人员具备专业的容器化技能，还需要转变原来传统的思维方式。
@沈卫忠 红帽高级方案架构师：
微服务，容器化的实质是解决了业务复杂性问题（通过微服务降低单模块的复杂度），提高了企业敏捷性，但代价是增加了运维的复杂度，因为微服务是分布式，而分布式是复杂，好在OpenShift/K8S提供了好多工具，能够帮助运维人员面对这种情况。所以运维人员需要具备一些新技能：
1. 首先是K8S，这个不用多说，PaaS平台的基础，什么pod, service, replicateset, statefulset, pv, pvc, K8S软件定义网络等等。
2. 容器技术: docker, CRI-O
3. ELK/EFK如何管理日志
4. 普罗米修斯/Grafana 监控
5. istio微服务治理框架
6. 分布式跟踪
7. 微服务网关
2、新老系统并行下服务调用过程还原？
【问题描述】新老系统并行，包括传统的soa架构系统，微服务架构系统，业务调用逻辑可能横跨新老系统，由于旧系统业务日志缺失比较厉害，在新老系统并行期间，对业务交易还原存在较大困难，没有一个比较好的方法去梳理业务调用逻辑，还原交易过程缺失的环节。
@沈卫忠 红帽高级方案架构师：
就OpenShift而言，OpenShift Service Mesh（基于Istio)是用于微服务治理的一个服务网格，这里面的Kiali和Jager可以帮助 梳理业务调用逻辑：
1. Kiali 可以帮助定义、验证并观察 Istio 服务网格。它所提供的拓扑结构可以帮助您了解服务网格的结构，并提供服务网格的健康状况信息。Kiali 实时提供命名空间的交互式图形视图，可帮助了解诸如电路断路器、请求率、延迟甚至流量图等功能。Kiali 提供了从应用程序到服务以及负载等不同级别的组件的了解，并可显示与所选图形节点或边缘的上下文信息和图表的交互。
2. Jaeger 提供了分布式追踪功能，可以在组成一个应用程序的多个微服务间追踪请求的路径。Jaeger 是一个基于厂商中立的 OpenTracing API 和工具。 主要有三个功能：
● 监控分布式事务
● 优化性能和延迟时间
● 执行根本原因分析
3、微服务化伴随着DevOps，如何快速的打造专业的运维开发团队？
@沈卫忠 红帽高级方案架构师：
DevOps不仅仅是技术层次的东西，而首先是一个组织架构、企业文化，没有组织架构和企业文化的改变，很难能够打造一个DevOps团队。
1. 打造一个DevOps团队，首先是业务流程的梳理：将业务需求从接收、整理、开发、测试、集成、验收到交付一个流程根据DevOps方法论进行梳理，确定对应人员、责任和过程。
2. 确定DevOps所需要的工具链和所需要的技能，进行人员赋能。
3. 有选择的使用一两个业务需求使用DevOps方法进行验证，并改进和优化流程，最终基本定型。
4. 实践并不断迭代优化
4、如何实现应用在容器、非容器上的统一编排管控？
@沈卫忠 红帽高级方案架构师：
这个问题我的理解是应用的某些技术组件是在容器平台上，另外一些技术组件是在非容器平台上（比如OpenStack或VMWare上面的虚拟机）。在这些的一种情况下，我们可以考虑采用Ansible自动化引擎通过编写playbook来统一编排调度。对于OpenShift和K8S，Ansible都有现成的module，如果这些module某些功能不支持，也可以调用Restful API.
如果想采用K8S原生的方式进行统一编排，可以考虑采用OpenShift或K8S内置的Operator Framework，利用Ansible和Operator-SDK创建一个Operator来统一编排容器外部和内部的应用。
5、容器化以后不同业务和数据之间的隔离如何实现？
@朱祥磊 某移动公司 系统架构师：
容器化后，容器之间共享同一个操作系统内核以及其他组件，在收到攻击之类的情况发生时，运行在这个节点上的容器，如果因为宿主机被攻击（甚至宕机），不能正常工作，容器编排引擎如kubernetes,会保证原来定义的副本实例数量，根据调度算法，在合适的其他节点再起新的容器，而且启动速度可以达到秒级启动，传统的宿主机启动则非常慢。而且k8s容器编排引擎还可以根据业务的访问量，进行pod的水平自动扩展（HPA）；如果采用传统的宿主机上运行大的单体，一个节点收到攻击，可能影响巨大，而且很难短时间恢复。业务之间可以通过域（namespace）来进行隔离。而且容器本身就已经实现了诸多的隔离功能。目前很多的世界知名企业都开始从传统的单体业务向容器化转型。
@沈卫忠 红帽高级方案架构师：
一般而言，容器本质上是进程的虚拟化（隔离），但操作系统内核是共享的，所以，在这一点上，容器的安全性没有虚拟机好。但是，我们可以通过以下方法增加安全性：
1. SELinux:
SELinux通过应用策略旅行将容器进程与主机分开
在进程，文件和系统级对象上设置标签，使用基于策略的规则控制权限，并根据策略执行Linux内核应用的规则
启用SELinux后，以特权权限启动的容器的风险也将降低
2. 精简化容器操作系统：红帽OpenShift采用了RHEL CoreOS，这是一个更加轻量级、更加安全、专门为容器定制的操作系统，从而减少了操作系统端的风险。
3. 容器镜像安全：这个要结合镜像仓库和镜像扫描工具。红帽本身提供了Clair镜像扫描工具和Quay的镜像仓库。同时，红帽官方提供了供免费下载的镜像：universal base image(UBI)，这些UBI都是经过检测过比较安全的。
4. 红帽OpenShift默认禁止容器以root用户启动（可以修改），可以防止潜在的漏洞。
对于数据隔离，一般而言，需要采取以下措施：
1. 不相关应用应该放在不同的OpenShift Project(相当于K8S namespace)，OpenShift Project之间采用基于角色的访问机制（RBAC）互相隔离。
2. Project之间可以采用软件定义网络的隔离（不同的VLAN)，防止网络之间的访问。
3. OpenShift将来的版本支持不同Project的pod/service分配在公有云或Openstack的VPC网段，进一步增加安全性。
现在K8S在这方面相比OpenShift功能比较欠缺。
6、Openshift如何实现有状态应用的支持？
@沈卫忠 红帽高级方案架构师：
对于用状态应用来讲，有三个方面跟无状态应用有着本质区别：
1、首先就是数据的持久化。这个需要存储的支持，OpenShift支持K8S的volume plugin以及最新CSI(Container Storage Interface)，能够支持多种存储后端，比如NFS, iSCSI, Ceph RBD, GlusterFS, VMWAre vSphere VMDK等。用户可以通过创建PV来创建存储资源，pod通过PVC绑定到对应的PV.我们可以根据对存储的使用情况（比如单读写，多读写，IOPS）等来选择不同的存储后端。这里顺便要提一句，红帽将会在明年1月份发布容器原生存储OpenShift Container Storage 4.2, 就是为了针对有状态应用的存储场景。OpenShift Container Storage 4.2基于Ceph, Rook和Noobaa三大技术打造，是一个容器原生的存储系统。
2、其次，pod不具有对称性，每个pod不能互相替换（这里可以是配置不同，数据不同等），在这种情况下，需要采用statefulset。
3、最好，对于用状态应用，启动和停止不是简单启停pod，可能还需要做一些额外的事情。这时候，Operator framework就出场。我们可以采用Operator Framework的Operator-SDK为有状态应用创建它的运维逻辑。
五、BSS/OSS应用容器化方案评估
1、电信企业BOSS系统未来转向容器云BOSS，那会面临哪些难点？技术上、业务上？
@朱祥磊 某移动公司 系统架构师：
1、现有应用业务量大、非常关键，彻底改造需要一个长期过程，可以先周边逐步渗透
2、人员技能不满足，传统运维模式，需要一个过程
3、应用改造需要较大的工作量，可能是投入很大的成本，投资收益比是否高，面临阻力
@沈卫忠 红帽高级方案架构师：
1、首先讲一些业务上的难点，这个比技术上更重要。没有业务上、企业文化和组织架构的改进，技术上的改进会被拖累。以前我们投资建设BOSS系统，如果你回头看，从97开始，然后是BOSS建设，基本上是一个个断续的投资周期，一般五年或10年一个周期，前两年开始建设，接下来是运维维保为主，这么一个投资模式，系统刚建设完成，业务匹配度较高，业务部门相对满意，随着时间的推移，业务的不满足性越来越多，即使中间修修补补，到最后往往是推倒重来，开始一个新周期，循环往复，技术的继承度不高。而如果用真正转向以云原生、微服务的现代BOSS系统，我们说采用的敏捷的开发模式，它的投资模式往往改为连续投入，而不是一次性一个大项目，这个可能对运营商比较困难改变。然后，组织架构和开发模式也应该对应修改，传统的建设和运维两条线肯定是一个拦路虎，至少目前来看也比较难以改动。还有，传统上，运营商的BOSS系统建设都是以厂商为主，或者采用交钥匙工程，运营商基本上只承担项目管理的角色，这样的一种模式是否能够适应敏捷的方式，至少从敏捷做的最好的互联网公司来讲，我们在那边没有看到这样的状况。即使还是采用厂商为主，管理厂商的方式可能也要有一些调整才会。
2、技术上来讲，我们国内的BOSS系统功能复杂，性能要求高，大的省基本都要5，6千万的用户，每天可能有几十亿的话单，尤其是对批价和计费的要求相对高。同时，微服务、云原生相对还比较新，有丰富经验的技术人员不多，刚开始如何进行领域划分不一定很到位，这些都给现代化转型创造了难题。所以，BOSS系统的微服务应该是演进的过程而不是革命的过程，它的方向应该是逐步将现有的单体BOSS应用逐步变小，从中抽取出微服务应用。
2、如何把握基于传统业务的微服务化和容器化时划分的粒度？
【问题描述】因运营商对业务的稳定性和连续性有比较高的要求，故容器化和微服化的演进路径必然是从边缘业务到核心业务，从简单应用到复杂应用，过于简单、并发度低的系统其实不必要作微服务化。同时相对一般的企业，运营商的硬件投入更大，服务器性能更高。过小过细的微服化不利于发挥硬件性能。容器化并非包治百病的良药，某些对并发吞吐量要求更高的业务，直接运行在裸机上，通过系统调优提高性能，容器化未必是最好的选择。
故如何在运营商容器化和微服化过程中，更好地把握划分的最小粒度是运营商容器化和微服务的一个重要问题。
个人认为至少有以下原则：
1、高并发，多业务聚合的应该坚决拆成容器化、微服务。而低并发，业务相对单一的不需要；
2、高I/O,如文件转移服务的不需要；
3、充分考虑主机性能，以保证业务吞吐量为第一原则来考虑拆分的必要性的粒度。
@朱祥磊 某移动公司 系统架构师：
微服务并不是越小越好，数量不宜过多，需要充分考虑到功能复用性、压力、开发工作量、团队等因素，以敏捷开发为原则。
@沈卫忠 红帽高级方案架构师：
就经典微服务设计而言，领域驱动设计（Domain Driven Design)是微服务拆分的常用方法，一般而讲，一个微服务合适的粒度是，有一个所谓的'两个比萨饼'的规则。这个是亚马逊提出的，意思是说一个开发团队不能多到两个披萨饼还不够他们吃的地步，往往是5到7个人。
对运营商业务来讲，微服务改造是一个循序渐进、逐步演进的过程，微服务的粒度也是根据业务要求相决定，有时候一个服务的粒度可能比较大一点，不一定是微服务，也可以是小服务（mini service, 几个微服务组合在一起）。
3、OSS是否有部署在容器化环境的相关成功案例？
@朱祥磊 某移动公司 系统架构师：
某运营商的在线计费系统，已经用了k8s+docker
@沈卫忠 红帽高级方案架构师：
在国内和国外，BOSS的容器化改造实际上早在一两年前就已经有了，有些运营商也已经上线了在K8S部署的容器化BOSS系统，这个包括咱们国内的某个省的移动公司，这个充分证明了容器化、微服务的BOSS系统是可行的。
4、对于容器化横向扩展有哪些建议？
@朱祥磊 某移动公司 系统架构师：
微服务的主要好处是一个服务“类型”可以通过使用多个容器实例和负载均衡来扩展以提供吞吐量。从而保证业务的高并发，稳定性。这也是容器化的一大优点。这个容器化的横向扩展，不是由容器本身实现的，而是通过容器编排引擎如kubernetes来实现的，也就是我们通常所说的pod的水平扩缩容（HPA ），当业务访问量大的时候，起更多的pod来影响用户的业务请求，当访问量小时候，还可以减小pod的数量。对于上面的来说，一般都是针对无状态的服务。而对于有状态的服务，如数据库,则要考虑下面的问题：“服务类型”的多个实例（即容器）共享同一个数据库实例；当在该数据库实例上进行了多个实例写入/读取时，这可能有性能瓶颈。任何事物都有两面性，所以，我们要辩证统一的去看，只有这样，才能让容器微服务更好的服务于我们的业务系统。
@沈卫忠 红帽高级方案架构师：
在容器云平台中，横向扩展包括两个方面：
1. 增加计算节点。就OpenShift而言，OpenShift增加了一个MachineSet的资源，OpenShift已经在AWS和AZure能够支撑动态增加节点，在私有云领域，OpenShift预期在下一个版本能够支持裸机的动态 横向扩展 。
2. 增加pod节点：这个是K8S的核心功能。可以通过手工调整deployment或者Horizontal Pod Autoscaler自动进行扩展。
5、基于OpenShift实现电信的BSS/OSS改造，相比基于原生K8S的优势点是什么？是否有实践案例？
@沈卫忠 红帽高级方案架构师：
1.K8S是一个容器编排平台，红帽公司本身是K8S社区的发起者和截止目前第二大社区贡献者，K8S是OpenShift的上游社区。
2. 红帽OpenShift是一个企业级的K8S平台，每个OpenShift版本都是基于某一个K8S社区版本，基本上对于每一个发布的K8S版本，红帽都会在该K8S版本发现数百个缺陷或bug,所以OpenShift都会对K8S版本进行加固，一般一个OpenShift版本会提供数百个功能缺陷修复和性能增强。
3. 同时OpenShift的定位是企业级的PaaS平台和FaaS平台，解决传统企业计算所面临的系统运维、共享应用服务（包括中间件、数据库等共享组件）和开发服务等三大方面的问题，提供了很多K8S本身没有的功能，比如轻量级的容器操作系统RHEL CoreOS，容器运行时，镜像仓库，SDN和网络隔离，存储，日志管理，性能指标和监控，基于角色的访问控制（RBAC),多租户，CICD和DevOps, 微服务治理Istio等。
4. OpenShift在全球有超过1000个客户，拥有全球最大的K8S客户数，包括在中国，也有不少金融和电信客户采用了OpenShift。具体到电信BSS/OSS业务支撑领域，全球最大的BSS/OSS厂商Amdocs跟红帽采用了强强合作的模式，他们的PaaS层是选用的红帽的OpenShift而不是自建K8S, 目前国外的一些客户正在落地过程中。
6、做应用的微服务改造，是否同时要进行企业数据中台和业务中台的搭建？
@sunphil 某移动 系统运维工程师：
微服务是为了进行能力拆分，打破系统间壁垒，为中台服务，服务更复杂的业务场景需求。
@沈卫忠 红帽高级方案架构师：
1. 中台是企业级能力复用平台，它本身往往就是通过API的方式暴露给前台面向客户的应用，也就是所谓的敏态应用。所以我们说，业务中台和数据中台的技术实现方式是微服务和云原生，这两者是相辅相成的。
2. 而且，业务中台和数据中台往往体现了企业组织架构的变化，往往能够推倒企业的微服务改造。技术上来讲，微服务改造初期是有前后台之分的，中台定位恰如其分。
7、为何BSS/OSS需要上容器和微服务呢？有什么难点？
@朱祥磊 某移动公司 系统架构师：
电信行业最核心的业务BOSS系统，即业务支撑系统，包括BSS和OSS，要求业务高可用，实时性，稳定性，安全性，业务需求变更频繁，需要频繁发布版本。传统业务系统存在的问题，一个模块出现问题，影响面很大，隔离性差，不具备快速发布等缺点。
而容器是一种轻量级的虚拟化技术，将应用和操作系统封装在一起，它具备资源隔离，性能隔离，故障隔离和网络隔离能力；同时具备快速发布，弹性伸缩和故障自动化恢复的能力，使得复杂的业务支撑系统得以落地生根，进而实现速度快，成本低，资源利用率高，系统稳定等IT系统支撑目标。
目前的难点：容器化和微服务化后， 应用数量增加，系统管理难度增大，需要积累和储备技术经验做运维开发保障。电信行业业务连续性要求高，现网系统复杂，需要对现网功能和架构做充分的梳理才能迁移业务。需要考虑硬件，操作系统，中间件，数据库的兼容性。
@沈卫忠 红帽高级方案架构师：
传统单体BOSS系统的主要问题是：
1. 系统复杂，业务需求变更困难，不能及时推出新业务，市场部门客户满意度低。
2. 不同模块耦和程度高。发布一个新应用，影响其他应用。有些时候一个应用被其他应用搞离线。
3. 硬件资源利用率低，扩展性也差。
4. 厂商锁定，运营成本高。
难点主要在于：
1. BOSS系统复杂，要求连续性、可靠性高，改造工作比较复杂。
2. 同时，技术相对比较新，有经验的技术人员不多，进一步增加了改造的风险。
3. BOSS厂商选用的通用软件开源社区版本质量不一定很高，如果BOSS厂商没有具备一定的开源能力，会造成BOSS系统的质量事故。
更多分享和解答，可点击文末阅读原文，到社区浏览 觉得本文有用，请转发或点击“在看”，让更多同行看到
相关推荐：
基于微服务、云原生架构进行BSS/OSS应用的现代化转型
http://www.talkwithtrend.com/Document/detail/tid/430941
欢迎关注社区 "OpenShift"技术主题 ，将会不断更新优质资料、文章。地址：
http://www.talkwithtrend.com/Topic/91779
下载 twt 社区客户端 APP
与更多同行在一起
高手随时解答你的疑难问题
轻松订阅各领域技术主题
浏览下载最新文章资料
长按识别二维码即可下载
或到应用商店搜索“twt”
*本公众号所发布内容仅代表作者观点，不代表社区立场