--摘要
2019年8月，我司承接了某市醫療集團，智慧葯房項目，該項目主要為集團下屬36家社區衛生服務中心提供葯品統一目錄管理、葯品集中采購、庫存管理、處方合理用葯審核、葯品配發、自動化發葯設備驅動提供軟件支撐。在該項目中我擔任了軟件架構設計師一職，主要負責該項目的軟件架構設計工作。本文以智慧葯房項目為例，主要論述了
微服務架構在項目中的具體應用，
該項目主經由葯品供應管理、處方審核、葯品配發、設備協同及葯房管理等模塊組成，子模塊之的業務相對單一，因為采用了微服務架構設計，將這些模塊進行了微服務設計開發及部署，使他們在后期迭代過程中，開發及發布不會影響到其它的模塊，通過使用
微服務架構設計，提高了軟件設計質量和開發效率，最終項目成功上線，並獲得了用戶一致好評。
--項目背景
根據深化醫葯衛生體制改革規范葯求，推進葯品集中采購，增加葯品的供應保障能力，嚴格監督管理，保障葯品的用葯安全，所有醫療機構開出的處方，必須通過處方審核后，方可進入划價計費環節，未經審核的處方，不得進行計費和配發。2019年8月，我司承接了某醫療集團智慧葯房項目，該項目為醫療集團下屬36家社區衛生服務中心提供軟件支持，主要分為葯品供應模塊、葯房管理模塊、處方用葯審核模塊、葯品配發模塊、設備協同模塊。葯品供應模塊負責葯品庫存預警，供社區衛生服務中心葯房對葯品進行集中采購，並將葯品發送到省采招平台；葯房管理模塊主要進行一些基礎信息的維護，及關注葯品的庫存管理，葯品批號跟蹤；處方用葯審核模塊，負責對醫生開出的葯品進行合理用葯審核，將不合理的處方審核結果返回給醫生，提醒醫生修改處方；葯口中配發模塊，負責將處方中的葯品進行調配，打印用法用量標簽，確認發葯后扣減相應的庫存；設備協同模塊主要是驅動葯房中的一些自動化發葯設備，將要葯品信息發給設備上位機，根據設備葯品的效期進行排序，通過上位機程序調用下位機，驅動設備出葯。在該項目中我擔任軟件架構設計師職務，主要負責軟件的架構設計及中間件等技術的選型工作。
--就當回答面試題
傳統的單體軟件架構在構建部署和擴展方面有很大的局限性，耦合度比較高，更新升級，都需要整體進行，隨着軟件規模的增大，業務模塊越來越多，分布式越來越復雜，合得軟件的構建變得越來越復雜，對開發人員的要求也越來越高，微服務是一種架構風格，根據業務務領域驅動分析，以垂直划分的方式將一個復雜的應用拆分成多個獨立自治的服務，服務與服務之間通過松耦合的形式進行交互，每個微服務都是單一的職責，以SOA的核心思想，以服務的形式對外提供服務，配合DevOps的一些組件，CI/CD持續集成每日構建，升級、擴容不中斷業務
--簡單介紹一下湊字數，后面分了三塊介紹，主要是前后台分離，怎么部署的；代碼層面是怎么垂直划分實現的
智慧葯房項目中，將葯品SPD采購入庫模塊、處方審核模塊、 葯品配發模塊、設備驅動模塊等模塊進行了微服務的划分，同時研發小組划分成了4個小組，每個小組負責模塊軟件的生命周期開發工作，從開發、集成、測試，再到微服務的發布升級。服務與服務之間通過 restful 接口進行控制集成。
前端表現層：由於智慧葯房項目，有設備硬件，所以前端表現層，采用了B/S+C/S的混合架構風格，在葯品采購入庫模塊中，采用了B/S的形式，將前端Web，通過Nginx 進行集群部署，當用戶通過瀏覽器訪問Web系統時，通過Nginx 輪訓加權算法，進行Web服務的訪問分配。通過Ajax方式調用 平台服務層的 Restful API接口。設備協同模塊，為了方便給下位機發送命令驅動設備，因此設備上位機采用的C/S架構，通過HttpClient 方式調用平台服務的 Restful 接口。
平台服務層：采用比較成熟的SpringCloud框架進行搭建，為表現示提供接口服務。將SPD采購入庫模塊、處方審核模塊、葯品配發模塊、設備驅動模塊等模塊接口啟動上線后通過Nacos注冊中心進行注冊，負責服務的注冊、發現。通過Gateway網關將所有的服務地址暴露在外，對外進行接口統一管理，並且在網關層，做了統一的安全認證，，當后端有多個服務時，通過服務命名管理，由Ribbon負責負載均衡的實現，當請求過多時，通過 Ribbon路由到指定的服務端，通過Skywalking進行接口鏈路的監控，確保接口服務對外的可用性。服務應用通過編寫 Dockerfile，通過Docker Compose將應用部署在Docker 上，提高了應用發布的效率，降低DevOps的復雜度
業務服務：按采購入庫模塊、處方審核模塊、葯品配發模塊、設備驅動模塊等業務分了多個微服務。各服務之間的調用通過Openfeign進行 RPC的動態調用。接口以Restful 的形式進行交互，處方審核接口服務調用頻率遠高於其它服務。並且及時性要求比較高，因為為審方服務提供了五個實例節點做集群服務，結合負載均衡解決服務端的請求壓力，審方合理用葯規則有18萬個葯品目錄，數據量較大，在做處方審核時對數據查詢的要求比較高，因此引入了Mongodb組件，MongoDB適用於大數據的存儲和分析。同時在設備協同模塊中，引用了Kafka MQ消息中心件，將設備和業務系統進行解耦，配發模塊將需要出葯的處方數據，發給Kafka，設備收到Kafka消息后，提取消息中的葯品數據，進行效期和庫存的排序，驅動下位機出葯。
--結尾
項目於2019年8月啟動到2020年10月歷時14個月，圓滿完成，順利完成驗收，並取得了客戶的一致好評，該項目運行一年多，也出現過一些小的問題，
由於醫院使用的是集團內部局域網，與外網隔離，給排查問題及維護增加了困難，一次發葯設備上的上位機不心小被葯房老師刪除后，不會重新安裝操作，上報我司后，我們聯系醫院信息科老師，在信息科的老師協助下，對軟件重新進行了安裝，此次事件，導致了設備停止工作了幾個小時，影響了葯房發葯效率。后來我司安排了1名售后維護該項目，這一年內也新增了一些發葯設備，由於選用了合適的微服務架構，使得設備的接入及服務的擴展變得非常容易，在售后同事的協助下，系統至今運行穩定。該項目的成功，讓我意識到了使用了
微服務架構的作用和價值，堅定了我對
微服務架構應用的信心，合理選擇合適的
微服務架構，能夠大大的提高了軟件設計的復用方法，加快開發的進程，在項目中起到事半功倍的作用。經過這次項目，我也看到了自己身上的不足之處，在未來還會不斷地更新知識，完善本系統的設計，使系統能夠適應國家醫改的變化需要，這是作為軟件從業的我為之努力的動力和方向。
系統架構設計師論文--通用模板 抽出來的方便記憶