二、技术选型
需求拿到手以后，我们就准备开发设计了，但是在真正开发设计之前，我先和探讨一下软件技术的问题。正所谓”磨刀不误砍柴工“，采取什么样技术去开发才是妥当的。
首先我们分析HIT软件需要运行环境问题。随着移动端应用普及，越来越多的应用需要运行在移动端。近年来，国家要求党政军事业单位软件国产化呼声越来越高，也就是以前windows平台是软件唯一平台已经受到挑战。据我最近一直测试使用deep linux操作系统的易用性，操作性，十分贴进国人的习惯是不错替代品。华为最近推出的操作系统，鸿蒙操作系统，据说是下一代操作系统。通过上述我们可以看出，我们开发的软件，理论上需要运行在各种屏幕（5.0英寸，5.0英寸，14英寸，20英寸等），各种操作系统（windows,linux,android,ios，鸿蒙）上。
目前有 2种占主流编程模式，B/S模式（也简称web开发），C/S模式。C/S模式优点，开发相对来说简单，缺点，不能跨平台，典型编程语言代表，pb,delphi。B/S模式：优点，能跨平台，缺点，开发相对来说复杂些,典型编程语言代表，java,php,python。
综上所述，目前世界上关于跨平台跨屏幕比较通用的成熟解决方案是使用web技术，有条件的医院尽可能使用B/S模式进行开发软件。
软件构架需要升级。 HIT软件经过这么多年发展，已经非常庞大了。 用户对软件依赖程度越来越高，软件越来越专业细化，产生了大量的HIT应用，软件架构复杂度空前提高。我想你一定听说过集成平台，而集成平台主要是面向服务的架构（SOA），我想你一定被下面这2张图片打动过，好像遇上了什么神丹妙药，你也曾听说过上了集成平台以后一团糟，事实并不是你想得那么轻松。
集成平台既然是一种新的面向服务架构解决方案，为什么用起来如此困难。回答这个问题之前，我先跟大家回忆一下软件设计里面的一个原则叫KISS原则，KISS是英文“Keep it Simple and Stupid”的缩写，意思是“保持简单和愚蠢”。KISS原则套在集成平台上面，你感觉左右都不对劲，哪里来的简单，这些发明SOA大佬怎么想的，这个也怎么符合KISS？重点来了， 集成平台到底符不符合KISS，我请你仔细看观察上面2张图，两个图实际都很复杂，但是第一张图明显比第二张图要复杂非常多，也就是说集成平台的本质用一个复杂的方法去解决比它更复杂的问题，依然满足KISS原则。既然满足那为什么用起来这么费劲，我跟你打个比方，我们以前骑自行车，突然给了你一台小汽车，你在没有考取驾照的情况下，直接开车上路了，肯定很费劲，发现倒车入库，左搞右搞都倒不进。我们是一群相当于没有考”驾照“的人，去开了“集成平台”的车当然费劲，所以我们花些时间考个“集成平台”的驾照，接下来让我们一起学习”科目一“。
”服务“的由来，在没有SOA之前，我们开发的程序都叫作单体应用，后来我们把发现单体应用某些通用的功能可以抽取出来给别人调用，这个抽取岀来的东西叫做”服务“，实现代码复用的目的。这样子说有些抽象，不过我举个例子你就明白了。
我以挂号业务为例，我们都知道现在有微信挂号、窗口挂号、自助机挂号非常多的渠道，假设微信挂号、窗口挂号、自助机挂号需要渠道我们开发3个APP。因为他们实现同一个功能---挂号，是否有通用功能，当然有。比如获取医生出诊信息、获取患者信息、生成挂号单等等，我们可以把它们封装一个”挂号“服务。为了便于大家理解，我画了一张图如下所示。
有丰富开发经验的工程师会问，怎么不把”挂号“服务，拆成3个服务，其实这个是微服务，如果是微服务，首先代码更复杂，运维维护也会更困难，我们不是把东西拆的越细越好，我们尽量把业务相关东西扔进一个服务里，尽可能减少数量，简化代码开发的难度，方便运维。以挂号为例子，服务的拆分考验我们对应业务深入理解，这也是为什么目前还有不少系统至今都没有基于”服务“来开发的原因之一。
我们有了”服务“这个功能，就需要管理，注册、发布、日志、监控、升级、订阅等等同功能，而这些功能在"服务"共用 的，所以我们有了ESB（企业数据总线）管理平台来管理服务。有一天，我们发现服务与服务之间需要通信，就引入”消息队列“非常便捷，消息队列专门为服务之间跑腿的，本质是实现服务之间的解耦，消息队列服务质量标准，至多一次，至少一次，恰好一次，用幂等性解决重复消息问题。如下图所示，生产发消息给队列，消息者去队列拉取消息，后来发一个生产者发送消息需要被多个消费者消费，引出订阅操作。因为消息队列十分重要，可以说不了解消息队列 ，你还站在”集成平台“的门外，要展开叙述会非常多的内容，我这里不展开了，大家花个时间需要专门学习一下，Kafka和RocketMQ都是非常优秀消息队列产品，大家可以了解一下。
HIT软件逐步迈向高可用（24小时在线）、高性能。高性能我暂不讨论，高性能有一个提前条件是医院的业务量超大。我重点与你讨论下高可用。HIT软件重要性几乎等同于水电，要求系统的稳定性越来越强。我相信再过N年，你打电话给领导，我需要停用2个小时，升级维护，这可能是一个最不好的笑的笑话。对于一个复杂的系统要实现高可用最有效的手段是实现冗余。什么意思，我想你一定听说过集群，集群的本质就是冗余。比方说你担心硬盘不可靠，搞3个硬盘做个RAID5，坏一块硬盘也没有关系；你担心整个服务器会坏，那就搞两台服务器，搞个双机集群；你担心整个机房都挂了，就来个异地容灾。ESB通常也是集群化部署，把服务发到多个节点上，一个节点挂了，还可以访问另一个节点。
那是不是冗余可以包办一切的呢？当然不是，比如说你发现你们医院某个应用系统非常的不好用，业务科室实在受不了，向上面打个报告准备换系统，切换系统你的业务有一段时间处于不稳定的状态。
举例说明，假设现在要换微信挂号，你发现原来的那些挂号的规则、获取医生出诊信息都要叫别人重搞一遍。你还记得当年为了把挂号规则了解清楚，当时你与业务科室舌战群儒花好大力气制定下来的，无意间可能还多了几根白头发。按照那以前的老方法，你上线了一个新单体应用，你向这位新合作伙伴提出需求，合作伙伴如期按照你的要求开发了一个程序。你收到测试程序，测试总是感觉有点不如意，你怎么没按照我的要求来做，对方也很委屈，我已经快马加鞭的把它开发完了，我觉得已经符合了你的需求了，是你没说清楚。如果是面向服务的编程，我提供几个接口给你调用就可以，因为挂号的业务规则我之前已经把它分装到服务里面了，新的APP要开发，你过来调用我的服务就可以了，也就是我们常说可以热插拔APP，避免系统升级所带来的业务不稳定。有条件的医院建议使用面向服务来开发软件。
最后小结，我之所以花很大篇幅写SOA，其实SOA在其他行业已经应用非常成熟，只有医疗行业最近几年才开始使用SOA，所以这一块我们比较陌生，以后系统架构逐步会过渡到面向服务，就尽可能把我学习到东西分享给大家，软件技术上推荐大家使用web技术来开发。
