医疗行业架构师心得

发现问题       

        13年医疗行业经验，从产品研发到现场交付，一直经历着这个行业付出与预期不对等的现状，最初以为是大家技术水准不够，当自身技术水平足够自信时依然无法撼动交付困难的现实，反思中认为是业务水平不足，技术与业务脱节导致的。身临现场交付的困境至今依然历历在目，五花八门的个性化需求冲击着原本的产品定位，自身数据体系与医院数据实际不是不兼容简直是两类物品，功能设计没有直击客户要害，数据类型服务交付过程居然产生了9成无用功。作为一名行业研发，普遍没有机会获取真正的现场需求，自然无法一次性解决掉行业困难，面对产品设计、实施描述、领导理念、测试标准时还要做不停的妥协，很多个必然的因素，影响着产品的满意度。

解决问题

       面对复杂的行业诉求，既想要产品研发保质保量，又让研发处于闭塞的办公室且多重受阻，矛盾的对立注定了大多数医疗产品的结局。资深行业架构师是破局的关键，但市面确实没有那么多，无论是现成的人才还是自我培养都需要结合医院需求，通过快速版本迭代来完成。

       行业代码夹杂着很多的个性化跟行业特性，无法毕其功于一役，架构师的概念里除了要在技术选型上选择适合的方案，还需要平衡交付压力、客户个性化需求、项目成本。比如数据类技术方案选型时可以选择数据湖构建方案，实现数据实时流程提取，采取hadoop存储，技术方案上没有任何问题，开发周期长、实施人员水平要求高、客户实时需求不强、数据量远没那么大时就会造成资源的巨大浪费及客户满意度的下滑。业务架构选型时，架构师会给出一套大而全的方案，模块过于细化，兼容各类型数据库，理念非常好，对于业务复杂的系统为了性能最佳只适合选一个数据库oracle或sqlserver，一个能用好就是产品的成功，模块细化带来的是资源跟成本的巨大开销在医疗业务领域要慎重。

         准备工作做好后，剩下的就是有序推进，但心里要做好准备，第一次不会成功，把所有模块业务、关联关系、访问效率摸清楚后，经过现场实践基于发现的问题，要准备二次、三次重构。有经验的架构师，一般都能做到一生、二熟、三成功。

技术方案

        业务系统技术选型时， 微服务小公司可以采用alibaba springcloud体系，主要组件为nacos、fegin/dubbo、gateway、sentinel结合sharding jdbc(最大数据量未突破3亿条时可以不用)。技术方案是非常成熟的，业务切分时尽量粗，具体思路结合阿里巴巴业务中台概念，比如订单模块、商品模块、支付模块每个模块独立的表达了一套可执行的概念，小规模或初次尝试时禁切分太细。toB项目尽量要求后端人员能操作前端代码，界面基础调整、接口对接有后端人员完成，前端人员参与组件封装、架构调整、界面美化等任务，交付时可以省去很多流程。并不是微服务总是好的，不大的系统单服务才是王者。很多敏捷开发平台，比如若依也提供了分离与非分离的框架解决方案，可以直接拿来即用。（抽取类的、打包类的、线程类的禁手搓，采用开源或成熟方案）

          数据类系统，可参考本人前期分布的现成方案，创作中心-优快云https://mpbeta.youkuaiyun.com/mp_blog/creation/editor/148536438        成长交给时间，成果交给用心勤奋的团队，祝您架构之路一路长虹。