构建互联网医疗平台架构平台，咱们尝试了用 DevOps 的形式，这个跟理论状况有间接关系。咱们过后的技术场景比拟多，业务场景极其简单。
后端
是 Spring cloud 形成的微服务，postgresql 作为主数据集库撑持互联网医院和互联网医疗业务中台两个平台的业务数据，redis 作为用户会话存储，RabbitMQ 作为业务预约队列应用，netty 作为即时消息通信应用。对立由 openresty 的 api 网关与客户端交互。
后端架构图比拟宏大，抽时间再画。
前端
状态更为简单，后期研发 app，分为两端，患者和医生，对立应用 flutter 缩小业务开发的工作量（不过也带来了对 flutter 技术深刻适配调试的工作量），前期又减少了 H5 的微信公众号，以及小程序。
集成环境
须要造成互联网医院 -> 医疗中台 -> 医院 HIS 的三端接口集成和数据合作，实现互联网处方和领取，能够间接同步至医院 HIS。
产品场景
产品面向的是不限度医院数量的架构，也就是能够通过配置，一直接入更多的医院进入互联网医疗平台，并且实现医疗 HIS 零碎的对接，领取缴费的协同。
云端应用 N o.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 流程，达到开发、测试部署、测试环境测试、生产版本升级、成产版本测试、网关重定向的过程。
返回读字节的知乎——理解更多对于大数据的常识
公众号“读字节”分布式，大数据，软件架构的深度，业余解读