软考架构设计师高分论文（微服务）
本人于2019年3月参与了某公司的焦点项目“在线问诊互联网医院平台”，该平台以在线问诊为焦点，分为用户信息管理、病历管理、保举处方、药品配送等功能。本人在该项目中担任架构师职位，主要负责团体架构设计和技术选型。本文以该项目为例，主要讨论微服务架构设计在项目中的详细应用。起首根据业务领域和技术实现不同，本着单一职责的原则将体系分别浩繁服务，办理了业务模块高度耦合的困难，其次拆分后的服务利用NACOS举行服务治理来办理服务不好管理，配置文件分散的题目，末了通过Netflix Hystrix实现服务的熔断降级。防止因某个服务非常从而导致雪崩效应，使整条服务链宕机的题目，整个体系历时1年半，于2020年九月上线，至今已稳固运行1年，深受用户好评。如今信息化时代，信息技术的快速发展以及“互联网+”概念的大力推进，为医疗行业的改革提供了一个新的探索方向，在这样的市场时代背景下，各种数据呈现爆炸式的增长，在线问诊体系开辟也开始逐渐流行，也逐渐出现利用计算机辅助诊断的案例，这种模式有效的实现线下患者分流，进一步减轻当前中国医疗康健体系的负担。我司在医疗行业深耕十几载，有良好的医疗底子，又拿下了互联网医院牌照，未来发展有巨大潜能，我司旧体系经过两年时间运行也累计了大量医疗数据，为未来智慧医疗打下坚实的底子，该项目主要以患者问诊，大夫接诊为主要功能，凭借问诊服从高，无论身在那边都能为患者提供便捷的优质医疗资源的优势让业务快速扩张，用户量飞速增加，从而也使需求更加快速变革，以前的单体项目显然已逐渐无法顺应我司对软件的要求，微服务改造刻不容缓。本项目组全体成员共41人，我在项目中担任体系架构师职务，我主要负责团体架构设计、技术选型、服务拆分等工作。
传统单体架构与微服务架构相比，以往的单体项目所有的功能模块都在一个历程中运行，各模块的之间的耦合度过高，关系十分紧密，基本是单个模块出题目，大概导致整个项目瓦解，各功能模块的扩展性很差，基本对某个功能模块举行扩展，经过调研，我们的体系将采用微服务的架构来举行开辟，微服务架构主要有以下特点，1.微服务把每个职责单一的功能放在一个独立的服务中。2.每个服务允许在一个独立的历程中。3.每个服务有自己的数据存储，现实上，每个服务应该有自己独享的数据库、缓存、消息队列等资源。4.每个服务有多个实例在运行，每个实例可以运行在容器化平台内，达到平滑扩展伸缩的效果。5.每个服务应该有自己的运营平台，以及独享的运营人员，这包括技术运维和业务运营人员。每个服务都高度自治，内部的变革对外透明。6.每个服务都可以根据性能需求独立的举行水平伸缩。本文偏重从微服务拆分，微服务治理，限流熔断在本项目中的详细应用效果来举行先容。
一、微服务拆分
通过分析焦点业务体系的需求，我们拆分服务承袭一个原则，就是不同微服务的边界明确，不重复开辟相同的业务，也就是职责单一原则。并且我们对数据库也举行来拆分，要求每一个服务都有自己的的数据库，不能直接访问其他服务的数据库。每个微服务可以将自己的业务袒露成服务，供其他服务举行调用。终极我们将焦点的业务体系拆分为：网关服务、认证中央折务、权限服务、用户中央折务、IM服务、付出服务作为底子服务层。诊疗服务、订单服务、处方服务、病例服务作为业务服务层。定时服务、文件服务、日志服务、分布式事务服务作为工具服务层。每个业务模块都是根据业务领域举行分别，同一个业务领域下因质量属性要求不同需要分别为两个服务，如认证服务和用户服务，由于认证服务是一个比较独立的模块，他只处理用户的登陆登出，作为应用的入口他的可用性和性能的质量属性要求相对较高。用户服务宕机不会影响认证服务。用户可以就登陆体系操纵订单，问诊等功能，使我们的体系容错率更高。
二、微服务的治理
由于原单体项目被拆分为浩繁服务，那服务斲丧者如何获取服务提供者的详细调用地址，因此引入了Nacos注册中央，每一个服务启动时都需要在注册中央举行服务注册，注册中央会生存这些信息如ip和端口的信息，以是每次服务斲丧者想要调用某一个服务的时候都可以在注册中央，通过服务名查询到对应服务的IP端口地址，来举行服务访问，服务斲丧者可以通过负载均衡的算法，从同范例服务列表中选择一个服务来举行远程调用，同时我们要求服务提供者每隔30秒向注册中央发送心跳请求，来确认其康健状态。假如注册中央感知到服务非常就会将其剔除。包管就算有非常服务我们还是能快速发现使其下线，包管体系的可用性，同时对于我们这么多服务的配置文件，我们也采用了nacos的配置中央来举行管理，比较好的一点支持动态配置，在某些功能的切换上面，比如：验证码单日条数的限制，日志的开关，我们都不用让服务重新发版，这也降低了在修改代码和发版过程中人为造成错误的风险。
三、限流熔断
在我们需求分析中，发现诊疗服务，依赖于IM服务、处方服务、订单服务，而处方服务和订单服务又依赖于其他服务，这样下去调用链路很长，也是我们的焦点业务，当诊疗服务的链路上有几个调用的子服务宕机大概耽误较高的话，会导致请求被堵住，堵住的请求会斲丧掉服务器的资源，当这些请求越来越多，服务来不及处理，慢慢的会导致其他的请求同样无法处理，末了导致整个业务体系卡顿乃至瓦解，调研发现现在最常用的服务依赖掩护是熔断和限流，我们通过Hystrix实现了断路器模式，当每个服务节点发生故障之后，通过断路器的故障监控，向调用方，返回一个符合我们预期的备选响应，还不是长时间的等候服务响应，这样包管了服务在整个调用链不会长时间的等候响应，不须要的占用资源，防止故障在整个微服务体系中伸张，末了乃至雪崩的情况发生。
项目在2020年9月份通过了终极验收，上线，至今以来体系运行也非常稳固，已经连续运行一年多，已有4W以上的大夫在平台注册，百万以上的患者得到服务，得到来客户一致的好评，在体系管理上每个服务都有专门的人来管理，提拔了产物的体验，也提拔了服务客户的质量和服从。同时每次发版也不会对整个体系发版，而是对某个修改的服务发版，面对需求也能快速响应，相比于之前的单体项目，体系逻辑更加清楚，面对日益增加的用户量我们也能通过各个服务的水平扩容来提拔体系的负载。但是微服务改造之后，产生了浩繁服务，运维的开销及本钱增加，后续会通过搭建devops平台，运维人员需要写好自动化运维脚本，通过自动化工具可以实现自动发布和监控，可以降低维护本钱，提拔上线交付服从和质量。
实践证实体系安稳运行与采用来合适的架构风格密不可分，经过此次微服务架构的应用方法，也看到不足之后，在未来还会不停更新知识，完善本体系的架构设计，使整个体系更加合理，更有效的服务于大夫和患者。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]