集成平台选型问题？
新一轮的医院互联互通评审开始后，医院信息科又遇到这样的场景问题，基于SOA的架构，由于历史的原因，遇到评审也过后，但是无法真正的运行起来，原因有以下几个方面的原因
1.沟通与协作成本高：新系统迫千业务需求和市场压力，急需上线，对负责的团队而言，与周边系统的对接和调试属于外部不可控因素，团队总是倾向千在内部可控的范围内解决问题， 因此会刻意避开对外部服务的依赖，选择自建相关功能，这样一来，系统间的交互会向着衰减的方向发展，重复建设也因此随之蔓延；
2.组织架构制约：团队往往缺乏为响应其他系统的诉求而改造和升级自身服务的意愿，因为新系统与他们没有直接的利益关系，医院也缺乏适当的奖惩机制促使各团队之间的积极协作， 本质上，这是组织架构决定的；
3.缺乏长效机制：SOA 改造常常是作为一个项目实施的，项目结束之后就不再有专门的组织和团队对SOA 架构进行持续把控了，后续新的系统在融入SOA系统时受到的支持就减弱了，而新系统本身提供的服务也缺乏必要的梳理和管控，有的新系统甚至不对外提供服务。
我们在做五级互联互通后，发现产品的架构无法适应新的要求，希望专家给支支招
1同行回答
1、SOA架构，是一种粗粒度、开放式、松耦合的服务结构，要求软件产品在开发过程中，按照相关的标准或协议，进行分层开发。
2、SOA体系架构主要是业务驱动IT， SOA通过所谓粗粒度服务接口和分级，确实提高了效率。实现流程化以后，也确实简化了开发难度。但是同时也给服务划分带来难题，如果说这个架构不能符合医院用户的实际需求，也确实不合适。如果所有厂商都进行 个性化开发 ，那么医院业务系统就更难集成。
3、所以 服务松耦合设计其实是一把双刃剑，在带来应变敏捷性的同时，也应该考虑类似的问题。
4、为了避免类似的问题出现，其实现在许多行业已经从SOA架构转向了微服务架构。
5、微服务架构其实和 SOA 架构类似,微服务主要是在 SOA 上做优化，其特点是将业务系统进行组件化和服务化。原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。所以只要对这些组建进行维护就可以了，新的开发商需要什么组建、服务和能力，只要他提出了，再把服务给他就可以了。可以更快的实现系统开发、上线和部署。同时避免SOA的诸多问题。
5、最后需要说明的一点微服务架构在部署的同时还需要对现有基础设施进行优化，最好采用基于容器的云原生运行环境。