互联网医疗平台架构项目，尝试了用DevOps的方式，这个跟实际情况有直接关系。我们当时的技术场景比较多，业务场景极其复杂。
后端是Spring Cloud构成的微服务，PostgreSQL作为主数据集库支撑互联网医院和互联网医疗业务中台两个平台的业务数据，Redis作为用户会话存储（互联网医疗的用户类型，分布情况很复杂）以及作为业务预约队列使用，netty作为即时消息通讯使用。统一由Openresty的API网关与客户端交互。
后端架构图比较庞大，抽时间再画。
前端
形态更为复杂，前期研发App，分为两端，患者和医生，统一使用Flutter减少业务开发的工作量（不过也带来了对Flutter技术深入适配调试的工作量），后期又增加了H5的微信公众号，以及小程序。
集成环境
需要形成互联网医院->医疗中台->医院HIS的三端接口集成和数据协作，实现互联网处方和支付，可以直接同步至医院HIS。
产品场景
产品面向的是不限制医院数量的架构，也就是可以通过配置，不断接入更多的医院进入互联网医疗平台，并且实现医疗HIS系统的对接，支付缴费的协同。
云端使用No.1云，后期根据业务需求又纳入了其他云（区域医疗的独立运营需求导致），因此云端部署复杂度非常高！
这个过程中我们的架构设计首先要解决的就是发布问题，微服务的使用是必须的，因为业务场景过于复杂，面向的客户特别多，单体统一发布就是一种灾难，但好处是医疗业务的应用架构形态比较清晰，很容易进行微服务的模块化划分，这样我们就形成了多个粒度适中的微服务。
部署
部署过程微服务和API网关都分成两个版本同时在云端运行，一个是Test，一个是Prod。为什么要使用这种形式呢？因为在复杂的业务与计算环境中，我们的测试环境尽量贴近实际生产环境是最好的，否则，测试出的系统如果上线，会因为生产环境的各种特殊情况而出现严重bug，那么这个过程中的反复回归测试，会导致大量的时间浪费，影响上线。
还有就是测试与生产差异过大的环境，会导致发布工程的过程涉及到的工程师之间交流更多，出现的实际变数更大，协调成本也就更高，甚至导致重复性再配置，再测试的循环煎熬。
我们的目标是Test环境的微服务进行严格的测试后，达到生产级别的需求和质量后，只需要push到生产环境的升级版本，再次经历升级版本的测试确认后，API网关对生产环境的指向更新到最新版本。
另外API网关还有下一级的Nginx，主要为前端H5提供发布服务和图片下载服务，一方面互联网医疗的患者图属于隐私级别，因此必须通过细粒度的用户/图对应关系形成ACL权限访问表进行健康图的访问控制；另一方面为了提升图访问的并发性能，API网关负载了通过2台图代理服务，代理服务通过LUA脚本访问数据库对当前回话用户进行ACL鉴权后，才可连接OSS访问健康档案图。
最麻烦的还是App的应用商店发布问题，一方面苹果的审核慢，第二方面有些内容审核过程必须屏蔽，否则很难通过，因此这也是生产环境必须使用多版本，尤其增加了审核版本，这与最终升级版本是不同的，那么即便是Android版本发布成功了，也不能直接提供最新功能，否则影响IOS用户的使用，必须等待IOS审核完成。
实际上网关很难在这个问题上独立实现统一版本调整，所以还要依赖App和后端版本管理进行一定的审核过程协调适配，审核未完成时仍要保持微服务的老版本，当审核成功后，App版本再与后端保持一致的动态升级，网关、H5也需要配合升级。这个过程往往出现在重大功能的升级过程。为了防止客户使用出现严重抖动，所以很难想象没有前后端开发、测试与QA、运维工程师的协同配合会是什么情况。
所以整个系统的后端从基础软件、微服务统一使用Docker部署，后端工程师和运维工程师对Docker的发布管理基本上直接在Docker管理工具中完成，也就是dev push -> test push -> prod version+1 -> api gateway redirect的Devops流程，达到开发、测试部署、测试环境测试、生产版本升级、成产版本测试、网关重定向的过程。
热门跟贴