京颐集团上云之路:如何助力中小型医疗行业信息化与全面上云?

从传统IT部署到云,人肉运维已经是过去式,云上运维该怎么开展?尤其是云2.0时代,运维已经向全局化、流程化和精细化模式转变。与此同时,人工智能的发展,“威胁论”也随之袭来——运维是不是快要无用武之地了?如何去做更智能的活?4月20日晚2017运维/Devops在线技术峰会告诉你!免费!有料!快点这里报名(https://yq.aliyun.com/activity/188


摘要:本次阿里云云栖社区行业圆桌论坛上,阿里云业务拓展专家刘慧(花名悠夏)、京颐集团(趣医)运维总监吴高成与阿里云业务架构师李虹(花名耘锦)共同探讨了京颐集团的上云实践之路,云上HRP的构建经验,云上数据库选型策略,对于运维自动化的认识以及医疗信息化的创新动力所在。对话行业大咖,引领云端科技,畅谈云上话题,尽在阿里云云栖社区行业圆桌论坛。


以下内容根据阿里云行业圆桌论坛视频整理而成。

本期嘉宾介绍:
吴高成,京颐集团(趣医)运维总监,从2013年进入京颐集团,之前曾从事软件开发、设计、测试、授权支持以及运维等方面的工作,目前主要负责京颐集团运维中心的整体规划和设计、优化以及运营服务的支持;
刘慧(花名悠夏),阿里云业务拓展专家;
李虹(花名耘锦),阿里云业务架构师。

京颐集团旗下的趣医网是从什么时候开始上云的呢?
吴高成谈到趣医网从建立之初就开始了上云之路,具体时间大约是在2014年的5月份。在趣医网上云的初期,管理层在进行决策的时候,当时会担心上云之后的安全问题、稳定性问题、如何做好运维工作以及如何管理好数据库的问题,这些都是管理层需要在决策中考虑的问题,后来京颐集团经过了局部产品的验证、测试以及上云的尝试,最终发现这条上云之路是可行的,所以之后就确定了云上运营的模式。

李虹也表示趣医网在很早之前就成为了阿里云的用户,在大数据和云计算技术刚刚开始兴起的时候,趣医网就选择了拥抱云计算。李虹谈到她曾经在2015年的年初的时候拜访过趣医,当时也聊到了趣医平台的架构和设计,其实趣医最为关注的就是医疗数据的安全性问题,因为这部分数据可能会涉及到个人隐私,所以趣医比较担心将数据迁移到云上是不是就将数据拿出去了的问题,以及如何保证数据安全的问题。其实当时阿里云就为趣医网提供一整套安全保障方案,包括云盾、云监控以及整体高并发的架构设计,这样就能更好地支持趣医将自己的系统部署在云端。

京颐集团目前哪些业务已经在使用阿里云了?
目前京颐集团的医疗云产品、互联网+以及医院+的平台、云培训、CRM、互联网医院、EMR、分级诊疗以及综合支付等数十种产品都已经上云了。

京颐集团在上云的过程中是否顺利?有没有比较有意思的故事可以与大家进行分享呢?
吴高成谈到趣医网从一开始就选择了上云的道路,并且趣医网的上云也比较顺利。要举个比较典型的例子就要谈到云HRP,以前的HRP针对的是传统医院内部的与人财物管理相关的业务,在后来趣医在选择HRP上云的过程中,也遇到了一些问题,因为传统的HRP使用的是Oracle数据库,这与云上的数据库不太一样,当转向上云的这条道路时就需要面临一个挑战,需要在云上选择与传统的方式中的Oracle数据库相比变动最小、成本最低的模式,所以在后来趣医上云的时候就选择了PPAS这样的模式。而这其中上云前后的运转模式也发生了变化,在传统情况下在线下运行时,可能不会像在云端那样需要面对那么大的并发量,当时因为可能没有考虑周全,甚至还走过一些弯路。举个例子来说,HRP是医院的一个人财物的管理平台,之前可能只是在医院内部使用,所以这个平台的业务量并不是非常高,而到云上之后,在某一时间业务量就可能出现高并发的情况,比如到了上班时间大家可能会比较集中地使用手机进行签到,这时候就会对于云端的数据库以及系统响应的性能就会有一些要求了。而当时趣医网对于数据库的读写分离策略考虑不周,而且对于缓存等技术都没有基于云端去进行考虑,这样就可能造成一些卡顿的问题,导致出现了无法签到的情况。后来趣医对问题进行了定位,并且在阿里云的大力支持下找到了问题的原因,主要还是基于云端的设计考虑的不够周全,所以趣医后来对这部分也进行了“补课”,最终使得平台的运转变得非常顺利,但是整个过程还是比较坎坷的。

李虹指出上云其实可以分成几个阶段,第一个阶段就是将应用部署到云端,第二个阶段就是基于云端对于应用进行架构上的优化,第三个阶段就是将应用与大数据技术以及容器工具更加完美地结合在一起。李虹还谈到自己印象比较深刻的就是京颐集团的预约挂号平台——趣医网这款产品,从创建一直发展到今天已经连接了1600多家医院,目前已经成为了在整个业界都非常知名的预约挂号应用。而之前趣医网在2015年和2016年逐渐发展的过程中,会有一些信息大会或者推广活动都是需要很多护航服务的,而在趣医的整体宣传活动的背后其实是京颐集团的运维技术同学和阿里的技术同学的通力合作来为趣医的宣传活动提供护航的及时响应,而当时趣医网需要面对的最主要问题就是如何保证数据库的稳定性以及如何实现读写分离方面的架构优化,进而对业务和应用进行良好的支撑,使得业务能够快速地发展。

京颐集团和阿里云之间的合作还是非常紧密的,那么京颐集团都使用了阿里云的哪些产品呢?在使用阿里云的产品之前和之后,京颐集团的业务发生了什么样的变化呢?
目前而言,京颐集团使用了很多阿里云所提供的常规服务,像ECS、RDS、PPAS、SLB、Redis以及Docker容器等服务都会使用到,并且在灾备这部分京颐集团也使用到了阿里云的DTS进行异地的灾备。吴高成谈到阿里云的常规服务,包括数据库的备份、导出以及镜像等京颐集团都使用的非常不错。他还谈到京颐集团在上云之后,首先人力成本投入降低了,不再需要投入那么多专业技术人员;其次,故障的监控和维护由阿里云负责提供,这就减少了趣医自己很多的工作量,之前出现故障时需要进行专业的分析,上云之后这部分的工作就减少了;第三个变化就是工作效率的提升,像之前提到的很多工作减少了,工作效率自然就提升了;第四点就是安全这部分,因为阿里云盾提供了一些基础安全服务,再加上比如像态势感知这方面的服务就为趣医提供了很大的帮助,因为阿里云是经过很多的项目验证的,所以可以说趣医对于阿里云团队的技术非常有信心,京颐集团选择上云这条道路是非常正确的,也是能够经受住考验的。

李虹谈到阿里云的定位是一家技术型的公司,目前阿里云80%的成员都是技术同学,所以阿里云一直在力争对于先进的技术进行研究并不断完善自身的产品。目前京颐集团使用了很多阿里云的产品,而且也使用了一些阿里云刚推出的还处于公测期的新产品,京颐集团也会考虑哪些场景会适合使用什么样的阿里云产品,所以可以说京颐集团也是阿里云一个非常重要的客户,这里可以引用王坚博士在《在线》这本书中说的一句话“衡量一个公司是不是互联网公司的标准一共有两点:第一点就是看它有没有使用云计算,第二点就是看它有没有使用大数据为用户提供更多有黏性的服务”,而京颐集团就是这样的一家公司。

吴高成也表示对于目前阿里云新推出的一些产品,京颐集团也在及时地进行跟进,比如像分库分表、分布式应用服务等,也希望在未来京颐集团可以成为在阿里云技术上“第一个吃螃蟹”的企业。

那么京颐集团使用的是阿里云的数据库服务还是使用的自建数据库呢?
吴高成在分享这部分时谈到这就需要回顾目前产品的应用情况,因为目前京颐集团的大部分产品都在向云端迁移,很多云下的产品都将会转向成为云端的应用,医疗云、医院+平台等这些都是基于云端的应用。在选择是使用自建数据库还是阿里云PPAS服务时,京颐集团也做过一些相应的分析,其实这两种方案各有各的优点。如果使用自建数据库,管理员需要自己安排,硬件的问题也需要自己管理,在维护的方面的成本比较大。那么为什么京颐集团选择了上云呢,其实就是对于基于Oracle的应用而言,像PPAS这些服务的技术兼容性比较高,从云下迁移到云上,对于数据库这部分并不需要担心太多,其次就是应用的调整和代码的调整的工作量比较少。可能之前在云下的时候实施的产品项目是针对单一医院的,而现在上云之后通过PPAS的VPD的扩展的功能可以很容易地把不同的医院在共享云的模式下进行实现,所以基于以上两点,趣医就选用了阿里云PPAS。

李虹也谈到HRP这样的医院人财物管理系统也就其实类似于企业的ERP系统,所以将前面的“E”换成了“H”代表Hospital,而对于HRP而言,国家也是有一定的要求的,国家要求县级以上医院都要使用HRP,也就是需要做自己的人财物管理。而京颐的产品云HRP为很多中小型医院提供了非常方便的服务,因为云端的HRP应用不只是将HRP部署到云端,其实还会提供很多的掌上的HRP的移动性的功能,再加上阿里的高级安全服务,即使在移动和互联网的模式下依然能为客户保障信息的安全,这一部分是属于在业务层面上的。第二部分就是在技术层面上的,其实很多的用户都存在这样的困惑就是选择自建数据库还是选择阿里云的数据库产品服务,其实对于医疗行业而言,使用到的很多的数据库都是Oracle,而阿里云的PPAS是基于全球比较知名的优秀开源数据库PG的,并且PPAS是高度兼容Oracle数据库的。而京颐的HRP产品也为大家在对于自建数据库和阿里云产品进行选择时做了一个标杆,此外就是阿里云的PPAS所提供的是集成了高可用、监控、灾备、恢复、运维以及迁移等一整套的解决方案的服务,其能够在数据库方面为用户提供更好的服务。

京颐集团在HPC的数据库选型实践上为其他基于Oracle的企业做了很好的典范。那么京颐集团在半年时间内,就有超过一千家的医疗机构上线,从这一点上来看,京颐集团所打造的医疗云已经成为国内医疗信息化IT基础设施,那么京颐集团是如何设计这一高可用、高可靠、高并发的架构的呢?
吴高成表示京颐集团在设计云上架构的时候就考虑到了以下几个方面的问题:

京颐集团上云之路:如何助力中小型医疗行业信息化与全面上云?

京颐集团云上架构图

  1. 架构设计需要支持微服务的设计,需要根据不同的产品走不同的微服务通道,并且彼此之间不会造成太大的影响。
  2. 将核心业务和非核心业务进行分类,非核心业务在业务量高发的时候可以采用降级的策略,并进行一定自动化的参数调整和配置。
  3. 通过数据库的读写分离来提高系统访问的流畅性,不会产生阻塞。
  4. 通过缓存和消息队列这样机制实现高业务量时的削峰。
  5. 在数据库架构中考虑根据不同的地区进行分区设计,趣医未来在华东地区、华南地区、北京地区以及东北地区都会根据业务的发展情况设计不同的数据库,比如可以根据患者登录的区域让其访问对应区域的数据库,这样整个数据库的质量和运行效果就得到了保证。
李虹也谈到应用在架构上的发展其实是一个渐变的过程,随着业务的不断发展,架构也需要不断地进行优化。最开始可能是负载均衡、然后是服务器、数据库这样的架构,服务器可以进行弹性伸缩,后面陆续到数据库的性能优化,引入到缓存以及消息队列,还有在系统之间进行的一些耦合,这就是架构整个的发展过程,后续还可能使用到Docker容器服务、DevOps以及大数据的应用并且不断完善架构的设计,来更好地支撑业务的发展。

企业上云之后,从运维层面最大的感受是什么?
李虹谈到在企业上云之后,从运维层面可能感受到最大的变化就是之前技术同学在自己的服务器旁边,可以直观地看到服务器的一些问题,现在则是通过云监控、通过短信等一些方式来通知运维同学,这样就减轻了运维的工作量和压力,这是很重要的一点。此外,阿里云其实也推出了一些护航服务、专家服务、数据库优化服务以及一些区域服务等,并帮助客户实现上云的部署、数据的迁移以及7*24小时的运维服务保证等,来帮助客户更好地实现云上的运维。

吴高成表示京颐集团需要面对的客户是中小型机构,这些机构往往存在一些比如像投入比较低,缺乏专业人才和统一规划的问题,而且相关产品的上线以及后续的维护也是比较困难的,使用也比较不顺畅,还会出现诸多的问题。而通过云端的运营模式就可以协助用户解决这些问题,这就与传统的运维之间存在的差异,总之上云之后最大的感受有几点,首先就是运维理念的转变,以前就是传统方式的运行维护,现在这样的维护方式就可能不合时宜了,无法满足用户的实际需求,京颐集团在未来也会沿着DevOps的方向,并且不断与阿里云进行沟通,在运维理念转变的前提下,探讨如何将运维工作做的更好。

京颐集团在推动国内医疗信息化过程中做出了卓越贡献,但是在医疗信息中,医患的隐私保护一直是被谈论最多的,再加上近期运维安全事件频发,比如炉石数据被删、MongoDB遭黑客勒索等事件先后发生,那么从技术上的角度而言,如何保证像京颐集团这样的企业的数据安全呢?
吴高成谈到京颐集团目前主要从架构设计的层面来保证与医疗相关的数据存储、传输的过程的数据安全,京颐集团架构上的安全维护主要分为四个维度:

京颐集团上云之路:如何助力中小型医疗行业信息化与全面上云?

京颐集团技术安全概要图

  • 第一个维度就是京颐集团对于数据库中的患者信息、身份信息都是通过加密的手段进行处理的。还会将用户信息中其他的关键字段通过比如像MD5这样的技术手段进行加密,并且通过技术实现对于关键数据访问的认证,保证数据存储的安全。
  • 第二个维度就是在数据传输层面,通过像HTTPS这样的协议保证数据存储和访问的安全,还有通过其他的一些像关键参数控制,确认数据时的互签认证以及握手机制的确认来保证合适的人拥有合适的权限来访问被允许访问的数据。
  • 第三个维度就是环境的安全,基于Linux环境进行设计来实现操作系统层面的安全,Linux有很多的安全相关的设计,另外通过像IP的访问限制,举例子而言像对于数据库的访问就是通过防火墙的机制和策略机制允许拥有特定IP的机器对与数据库进行访问,这样就保证了数据库不会直接地对外开放,进而保证了环境的安全。
  • 最后一个维度,对于京颐集团整体的产品安全支持服务而言,运维是一个非常重要的环节,通过运维的双人值守、自动报警以及短信提醒机制来及时地对于系统中出现的安全隐患和故障进行监督和监控并进行处理。
通过以上四个维度的处理,就能够确保数据的安全。

那么阿里云架构师从云计算的方面对于安全有什么看法和见解呢?
李虹谈到今天提到的安全其实都属于互联网安全,因为数据和用户都可能在互联网上,这其实就涉及到从网络安全到系统安全再到主机安全等等一系列的安全保障措施,目前阿里云已经有了先知计划、Web应用防火墙、态势感知等等一系列的安全产品,能够帮助客户及时检测一些安全的风险,提供世界级的安全服务和产品,阿里云有信心与京颐一起保证云上数据和应用的安全,支撑业务的平稳运行。

从以上这些来看,京颐集团无疑是国内医疗卫生信息话建设上的领跑者,之所以能有那么多的创新模式,主要是得益于什么呢?
吴高成表示京颐医疗的包括医疗云在内的相关产品都使用了云模式,其实可以拿京颐集团的某一个数据中心为例向大家进行介绍,京颐医疗某个地区的数据中心是通过云端模式来实现地区相关医疗卫生服务的平台,据最新的数据统计每天的门诊量已经达到了4万1千左右,目前这样的门诊量已经超过了国内任何一家三甲医院的量,这是区域卫生医疗的一个典范。

从应用实践上来说,通过云端模式京颐医疗主要有这么几个体会,可以总结成为几个字,第一个就是“稳”,阿里云非常稳定并且可靠,这就是云平台所提供服务的一个基本特质,云平台可以通过多重的安全保障以及后台的技术支持来实现这样的目标,通过京颐集团上云之后对于云平台的应用情况,发现“稳”是位于第一位的。第二个字就是“快”,整个项目的上线比较快,周期比较短,举例而言,像趣医平台在三到六个月的时间,上线的医疗机构就超过了一千家,这在之前是不可想象的,或者需要非常长的时间才能完成相同的目标,而现在通过云模式,就可以达到部署快,上线快,维护方便。第三个字就可以用“省”字来形容,无论是对于提供服务的京颐集团而言还是对最终的医疗机构或者用户而言,都能够极大地降低投入的成本,对于之前线下的项目进行统计发现投入的硬件成本和维护成本的比例接近整个项目投入的60%,目前维护费用就完全足以支付云端的投入,所以这就是第三个字“省”。第四个字总结而言就可以用“用”这个字来形容,因为对于云端的应用而言,其本身的技术架构以及扩展性就可以无缝地支持业务的平滑升级,这样就对于未来的分级诊疗、网络医院等诸多的新兴的医疗卫生服务能够提供具有非常好的扩展性的平台。所以目前而言上云是医疗卫生行业发展的大趋势,京颐集团也将沿着这条道路坚定地走下去。

李虹也谈到最近在医疗领域包括一些区域卫生的项目,其实不只是一家医院的信息化建设,医院之间的数据共享、数据的互联互通以及打通下级医院到上级医院转诊的分级诊疗等等模式都需要更大的平台进行支撑。就像刚才提到的趣医某一个区域的数据中心就能够达到每天4万多的挂号就诊量,阿里云也希望能够在这个平台上起到更多的作用,在医疗卫生信息化方向也能够拥有更多的行业的以及区域的案例。

那么作为运维总监,能否分享一下DevOps和Docker在云上的实践呢?
吴高成谈到对于DevOps这个思路以及设计思想,京颐集团也做了一段时间的跟踪和研究,目前无论是在国内还是国外,DevOps这个方向都是大势所趋,大家都在沿着这个方向向前走,京颐集团也曾经做过相关的产品实践。京颐集团的护理教育部在2016年的1月份就开始着手研究DevOps方面的实践应用,而且在这一方面也使用到了Docker技术。对于京颐集团的护理教育事业部而言,主要做了几点工作,因为Docker技术应用交付的速度比较快,从开发应用到镜像的构建再到容器的部署,这样的一条线是非常顺利的。第二就是Docker可以集成局域网的相关的网络配置,可以将网络配置的相关参数打包进入镜像中,可以解决因为网络发生变化所带来的调整参数的工作量。第三个优点就是基于Docker技术构建的应用可以达到秒级的启动,而且这对于云端应用而言也是非常重要的。在这三个方面京颐集团的护理教育事业部都实践的比较好,目前已经实现了和护理教育相关产品的持续集成,将应用环境全部打通,并将VPC系统进行了整合,从应用的规范和及时性上也提高了工作效率;而在应用的另一个维度,优点就在于动态扩容,京颐集团目前也进行了一定的尝试,但是还需要进一步的验证,不过从目前应用的结果来看,效果还是非常不错的,也准备在其他事业部的项目和产品上进行推广。

李虹指出目前Docker等技术的确为运维工作带来了很多的变化,对于业务部门而言,Docker就是带来敏捷性的变化,能够快速响应市场一些需求的变化,而对于信息部门而言,可以降低风险,进行有效运维同时提供了极强的可扩展性。阿里云目前的Docker技术可以实现海量容器的支持,秒级启动、故障恢复以及自动伸缩,阿里云欢迎越来越多追求互联网前沿技术的公司尝试阿里云所提供的Docker服务。

人工智能将成为未来必不可少的运维工具,作为运维总监,对于这个方面有什么看法呢?
刚才我们提到了DevOps的概念,其实沿着这个方向走是大势所趋,就个人的总结和体会而言DevOps主要解决了技术研发、运维运营以及质量保障这三个方面的主要工作,它类似于在产品交付的过程中提供IT框架服务的概念。所以沿着这个方向不断使用像Docker这样的前沿技术,不断细化深入,进而提高工作效率。而对于智能化和人工智能技术而言,总体的发展情况还是非常好的,但是目前而言想要实现运维的人工智能,就需要首先将所有的业务流程和工作流程先实现自动化,在自动化的基础之上再借助人工智能的技术和手段进行逐步推进,所以就个人而言,京颐集团应该首先实现运维的自动化,这是比较实际的任务。
上一篇:复星战略投资以色列科技金融平台The Floor,加速其全球业务扩张


下一篇:《RocketMQ技术内幕:RocketMQ架构设计与实现原理》—1.1.1 Eclipse获取RocketMQ源码