搭建互联网医疗平台架构平台，我们尝试使用DevOps，这直接关系到实际情况。我们当时的技术场景非常多，业务场景极其复杂。后端是由SpringCloud组成的微服务。以Postgresql为主要数据集数据库，支撑互联网医院和互联网医疗服务平台两大平台的业务数据。Redis作为用户会话存储，RabbitMQ作为业务预约队列，netty作为即时通讯。使用。openresty的api网关统一与客户端交互。后台架构图比较大，有时间再画一遍。前端形态比较复杂，前期开发的app分为患者和医生两端。统一使用flutter减少了业务开发的工作量（但同时也带来了flutter技术深度适配调试的工作量），后期增加。H5微信公众号、小程序。集成环境需要形成互联网医院->医疗中台->医院HIS的三端接口集成和数据协同，实现互联网处方和支付，可直接同步到医院HIS。产品场景产品面向不限制医院数量的架构，即通过配置，可以不断将更多的医院接入互联网医疗平台，实现医疗HIS系统的对接和支付与支付的协同。支付。云中使用No.1云，其他云后面根据业务需要（区域医疗独立运营需求导致）合并，所以云部署的复杂度非常高！在微服务的过程中，我们的架构设计首先要解决发布的问题。使用微服务是很有必要的，因为业务场景太复杂，客户太多。单个单元统一发布是灾难，但是好处是医疗业务的应用架构比较清晰，容易模块化微服务，这样我们就形成了多个粒度适中的微服务。部署过程微服务和api网关分为两个版本同时运行在云端，一个是Test，一个是Prod。为什么要使用这种形式？因为在复杂的业务和计算环境中，我们的测试环境最好是尽可能接近实际的生产环境。否则测试系统上线后，由于生产环境的各种特殊情况，会出现严重的bug。反复进行回归测试，会导致大量时间浪费，影响上线。还有就是测试和生产差异过大的环境，会导致项目发布过程中参与的工程师之间的沟通较多，实际变量较大，协调成本较高，甚至需要反复重新配置。测试周期很折磨人。我们的目标是，测试环境的微服务经过严格测试，满足生产层面的要求和质量后，只需要推送到生产环境的升级版本即可。升级版本再次测试确认后，api网关会指向生产环境更新到最新版本。另外，图库的API网关还有下一层的nginx，主要为前端H5提供发布服务和图片下载服务。一方面，互联网医疗的患者图像属于隐私级别，因此必须通过细粒度的用户/图像对应关系形成ACL权限访问。表控制对健康图的访问；另一方面，为了提高图访问的并发性能，API网关加载了两个图代理服务。代理服务通过LUA脚本访问数据库，在连接OSS访问健康记录图之前，对当前会话用户进行ACL认证。最头疼的是应用商店发布问题。一方面，苹果审核速度慢。另一方面，有些内容的审核流程必须要封堵，否则很难通过。所以，这也是生产环境必须使用多个版本，尤其是加了review版本的时候。不同于最终升级版，所以即使android版发布成功，也不能直接提供最新功能，否则会影响ios用户的使用，必须等待ios审核完成。事实上，网关很难在这个问题上独立进行统一的版本调整，所以还需要依靠app和后台版本管理来协调适配一定的审计流程。当审计没有完成的时候，旧版本的微服务还是要维护的。当审核成功后，APP版本动态升级与后台一致，网关和H5也需要相应升级。这个过程经常出现在主要功能的升级过程中。为了防止客户在使用中出现严重的抖动，很难想象没有前端开发、测试、QA、运维工程师的配合会发生什么。所以整个系统的后端从基础软件和微服务统一采用docker部署。后端工程师和运维工程师对docker的release管理基本直接在docker管理工具中完成，即devpush->testpush->prodversion+1的devops流程->apigatewayredirect到达流程开发、测试部署、测试环境测试、生产版本升级、生产版本测试、网关重定向。前往读字节的知乎——了解更多大数据公众号《读字节》分布式、大数据、深度软件架构、专业解读
