CN113921130A - Cloud-native-based smart medical cloud ecological service method, equipment and storage medium - Google Patents
Cloud-native-based smart medical cloud ecological service method, equipment and storage medium Download PDFInfo
- Publication number
- CN113921130A CN113921130A CN202111044182.9A CN202111044182A CN113921130A CN 113921130 A CN113921130 A CN 113921130A CN 202111044182 A CN202111044182 A CN 202111044182A CN 113921130 A CN113921130 A CN 113921130A
- Authority
- CN
- China
- Prior art keywords
- service
- medical
- cloud
- micro
- layer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 55
- 238000003860 storage Methods 0.000 title claims abstract description 16
- 238000009434 installation Methods 0.000 claims abstract description 21
- 230000003993 interaction Effects 0.000 claims abstract description 20
- 238000004590 computer program Methods 0.000 claims description 18
- 238000012423 maintenance Methods 0.000 claims description 10
- 238000004891 communication Methods 0.000 claims description 8
- 230000008859 change Effects 0.000 claims description 6
- 238000012544 monitoring process Methods 0.000 claims description 6
- 238000011156 evaluation Methods 0.000 claims description 3
- 230000004931 aggregating effect Effects 0.000 claims description 2
- 238000003745 diagnosis Methods 0.000 claims description 2
- 206010002091 Anaesthesia Diseases 0.000 claims 1
- 230000037005 anaesthesia Effects 0.000 claims 1
- 238000007726 management method Methods 0.000 abstract description 9
- 238000011161 development Methods 0.000 description 10
- 230000008569 process Effects 0.000 description 10
- 238000005516 engineering process Methods 0.000 description 6
- 238000002955 isolation Methods 0.000 description 5
- 239000008186 active pharmaceutical agent Substances 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 230000010354 integration Effects 0.000 description 3
- 238000012360 testing method Methods 0.000 description 3
- 238000004458 analytical method Methods 0.000 description 2
- 230000003139 buffering effect Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 244000025254 Cannabis sativa Species 0.000 description 1
- 235000012766 Cannabis sativa ssp. sativa var. sativa Nutrition 0.000 description 1
- 235000012765 Cannabis sativa ssp. sativa var. spontanea Nutrition 0.000 description 1
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 235000009120 camo Nutrition 0.000 description 1
- 235000005607 chanvre indien Nutrition 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000000354 decomposition reaction Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 239000003814 drug Substances 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 239000011487 hemp Substances 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 239000004973 liquid crystal related substance Substances 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 239000000178 monomer Substances 0.000 description 1
- 238000004806 packaging method and process Methods 0.000 description 1
- 230000002265 prevention Effects 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
- G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
- G16H40/67—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
- G16H40/20—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45562—Creating, deleting, cloning virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45595—Network integration; Enabling network access in virtual machine instances
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Health & Medical Sciences (AREA)
- Theoretical Computer Science (AREA)
- Biomedical Technology (AREA)
- General Business, Economics & Management (AREA)
- Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- Epidemiology (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Primary Health Care (AREA)
- Public Health (AREA)
- Medical Treatment And Welfare Office Work (AREA)
Abstract
The application relates to a cloud ecological service method, equipment and a storage medium for smart medical treatment based on cloud protogenesis, belonging to the technical field of smart medical treatment, wherein the method comprises the following steps: splitting the service into a plurality of micro services, and constructing a micro service architecture; under the condition of receiving an installation request sent by a medical end, sending an application program installation package based on a micro-service architecture to the medical end so that the medical end automatically completes installation and deployment; when the patient end and/or the doctor end and the medical end carry out service interaction, the service container is operated, and scheduling management is carried out through Kubernetes. Therefore, in the application, the delivery efficiency can be improved for the split micro-services, and due to the independence among the micro-services, when a fault occurs, the influence is small, and the overall usability is improved; in addition, the framework is easy to continuously evolve, and the expandability is high.
Description
Technical Field
The application relates to the technical field of smart medical treatment, in particular to a cloud ecology service method, equipment and a storage medium for smart medical treatment based on cloud protogenesis.
Background
With the rapid development of science and technology, a lot of medical services can be completed on the line, so that the doctor can see more and more conveniently, and the people are helped to save a lot of economic cost and time cost. However, from a technical point of view, the prior art smart medicine adopts a monolithic architecture, that is, each large class of business systems is deployed in a form corresponding to a single large service, which may cause many drawbacks, for example, a slow delivery speed; when a fault occurs, the influence range is large, even the integral service is influenced, and the integral usability is low; various problems are caused in the case of large-scale reconfiguration, and the continuous evolution of the architecture is difficult and the expandability is low.
Disclosure of Invention
The embodiment of the application provides a cloud-based intelligent medical cloud ecological service method, equipment and a storage medium, and aims to at least solve the problems that the overall availability of a single service architecture is low, the continuous evolution of the architecture is difficult and the expandability is low in the related technology.
In a first aspect, an embodiment of the present application provides a cloud-based smart medical cloud ecological service method, which is applied to a cloud platform side, and the method includes: splitting the service into a plurality of micro services, and constructing a micro service architecture; under the condition of receiving an installation request sent by a medical end, sending an application program installation package based on the micro-service architecture to the medical end so that the medical end automatically completes installation and deployment; and when the patient end and/or the doctor end performs service interaction with the medical end, operating the service container and performing scheduling management through Kubernetes.
In some embodiments, the service interaction between the patient end and/or the doctor end and the medical end comprises: and the patient end and/or the doctor end performs service interaction with a service layer of the medical end through an access layer gateway, wherein the service layer comprises a BFF layer, and the BFF layer is used for aggregating backend services, controlling access authority and caching application data.
In some of these embodiments, the method further comprises: interacting with a third party outside the smart medical cloud ecology through the BFF layer.
In some of these embodiments, the service container supports at least one of a HIS, an EMR, a PACS, a LIS, and a hand linen system.
In some of these embodiments, an API interface based on RPC remote calls is employed for communication in the smart medical cloud ecosystem, wherein the RPC employs a Dubbo framework.
In some embodiments, after the medical end automatically completes the installation and deployment, the method further comprises: when the micro service version is updated, sending a change notice to an operation and maintenance platform of the medical end; and under the condition of receiving an updating request sent by the operation and maintenance platform, sending a container mirror image installation package to the medical terminal so as to enable the medical terminal to be automatically updated.
In some of these embodiments, the method further comprises: uniformly managing the configuration files on each medical terminal, and uniformly storing the service logs; and analyzing the service log, knowing the operation condition of the service system and monitoring the operation condition.
In some embodiments, the content of the service interaction between the patient side and the business layer of the medical side comprises at least one of self-service card handling, appointment registration, online inquiry, online consultation, online party continuation, report viewing, medical record viewing, expense settlement, message notification and satisfaction evaluation;
the content of service interaction between the doctor end and the service layer of the medical end comprises at least one of cloud diagnosis, on-line consultation, electronic prescription, third-party pharmacy, special orientation, journey consultation, MDT service, on-line education and on-line follow-up visit.
In a second aspect, an embodiment of the present application provides an electronic device, including a memory and a processor, where the memory stores a computer program, and the processor is configured to execute the computer program to perform any one of the methods described above.
In a third aspect, an embodiment of the present application provides a storage medium, in which a computer program is stored, where the computer program is configured to execute any one of the above methods when the computer program runs.
The cloud ecology based intelligent medical cloud ecological service method provided by the embodiment of the application comprises the following steps: splitting the service into a plurality of micro services, and constructing a micro service architecture; under the condition of receiving an installation request sent by a medical end, sending an application program installation package based on a micro-service architecture to the medical end so that the medical end automatically completes installation and deployment; when the patient end and/or the doctor end and the medical end carry out service interaction, the service container is operated, and scheduling management is carried out through Kubernetes. Therefore, in the embodiment of the application, the delivery efficiency can be improved for the split micro-services, and due to the independence among the micro-services, when a fault occurs, the influence is small, and the overall usability is improved; in addition, the framework is easy to continuously evolve, and the expandability is high.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:
fig. 1 is a schematic view of an application scenario of a cloud-based smart medical cloud ecological service method according to an embodiment of the present application;
fig. 2 is a flowchart of a cloud ecology service method for cloud-based smart medical services according to an embodiment of the present application;
fig. 3 is a schematic diagram of an internal structure of an electronic device according to an embodiment of the present application.
Detailed Description
In order to make the objects, technical solutions and advantages of the present application more apparent, the present application will be described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments provided in the present application without any inventive step are within the scope of protection of the present application. Moreover, it should be appreciated that in the development of any such actual implementation, as in any engineering or design project, numerous implementation-specific decisions must be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which may vary from one implementation to another.
Reference in the specification to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the specification. The appearances of the phrase in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Those of ordinary skill in the art will explicitly and implicitly appreciate that the embodiments described herein may be combined with other embodiments without conflict.
Unless defined otherwise, technical or scientific terms referred to herein shall have the ordinary meaning as understood by those of ordinary skill in the art to which this application belongs. Reference to "a," "an," "the," and similar words throughout this application are not to be construed as limiting in number, and may refer to the singular or the plural. The present application is directed to the use of the terms "including," "comprising," "having," and any variations thereof, which are intended to cover non-exclusive inclusions; for example, a process, method, system, article, or apparatus that comprises a list of steps or modules (elements) is not limited to the listed steps or elements, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus. Reference to "connected," "coupled," and the like in this application is not intended to be limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. Reference herein to "a plurality" means greater than or equal to two. "and/or" describes an association relationship of associated objects, meaning that three relationships may exist, for example, "A and/or B" may mean: a exists alone, A and B exist simultaneously, and B exists alone. Reference herein to the terms "first," "second," "third," and the like, are merely to distinguish similar objects and do not denote a particular ordering for the objects.
Aiming at the defects of the monomer architecture adopted by intelligent medical treatment in the related technology: the delivery speed is slow; the fault isolation range is thread level, and the influence is large; the overall usability is low; the architecture has difficulty in continuous evolution; the communication efficiency is low; technology stack selection is limited; scalability is limited; limited reusability; service complexity decomposition is difficult; the product innovation complexity is high.
In order to overcome the above-mentioned drawbacks, an embodiment of the present application provides a cloud-based smart medical cloud ecological service method, and fig. 1 is a flowchart of the cloud-based smart medical cloud ecological service method according to the embodiment of the present application, as shown in fig. 1, the method includes the following steps:
s101: splitting the service into a plurality of micro services, and constructing a micro service architecture;
s102: under the condition of receiving an installation request sent by a medical end, sending an application program installation package based on a micro-service architecture to the medical end so that the medical end automatically completes installation and deployment;
s103: when the patient end and/or the doctor end and the medical end carry out service interaction, the service container is operated, and scheduling management is carried out through Kubernetes.
Therefore, in the intelligent medical cloud ecology, based on the micro-service architecture, the service is operated based on Docker containerization, and scheduling management is realized by Kubernetes, so that DevOps (development, operation and maintenance integration) can be fully supported. It is worth to be noted that the cloud-based intelligent medical cloud ecological service method in the embodiment of the application is applied to a server, namely a cloud platform, and the cloud platform is used for storing an application program installation package developed by an ecological manufacturer and providing support for application market and application deployment and installation; and initiating a request to the platform through the in-hospital application market service to acquire an installation package of the corresponding application so as to achieve the purpose of automatic installation and deployment in the hospital.
The Medical terminal provides support for the development of Hospital services, and thus, the service container may support HIS (Hospital Information System), EMR (Electronic Medical Record), PACS (Picture Archiving and Communication Systems), LIS (Laboratory Information Management System), and hemp System.
The patient side can provide services for the patient in the forms of a mobile phone App, a computer WEB side, a WeChat applet and the like, and the contents of service interaction between the patient side and a business layer of the medical side include but are not limited to self-service card handling, appointment registration, online inquiry, online consultation, online party continuation, report viewing, medical record viewing, expense settlement, message notification, satisfaction degree evaluation and the like. The patient side interacts with the service layer of the medical side through the access layer gateway, and the safety equipment such as a firewall, intrusion detection, a gatekeeper and the like is used for authentication and protection so as to ensure the safety of data interaction between the internal network and the external network.
The doctor end can provide doctor online medical service by being supported by the forms of a mobile phone App, a computer WEB end and the like, and the contents of service interaction between the doctor end and a business layer of the medical end include but are not limited to cloud consultation, online consultation, electronic prescription, third-party pharmacy, special orientation, remote consultation, MDT (Multi Disciplinary team) service, online education, online follow-up visit and the like. The doctor end also interacts with the business layer service of the medical end through the access layer gateway.
As an example, the patient end and/or the doctor end performs service interaction with the service layer of the medical end through the access layer gateway, and the service layer includes a bff (backup For fronted) layer, which is detailed as follows:
(1) in a multi-end application scenario, the requirements of different devices are considered when designing an API, and although they may implement the same function, because of the particularity of different devices, API access to a server by the different devices also has their characteristics, and needs to be handled differently.
(2) Because the service is split into a plurality of micro-services, the business process originally running in the same process is split into different services. This makes the front-end invocation more complex while increasing the flexibility of the service. The BFF layer provides an aggregation point for service calls to the business services for the front-end application, which masks the complex service call chain, allowing the front-end to focus on the required data without concern for the underlying service providing the data.
(3) And the authority control in all services is centralized in a BFF layer, so that the lower-layer services are more pure and independent.
(4) Some temporary data needing buffering often exist in the project, and the BFF is used as a convergence point of the service and is closest to the user request, so that the buffering operation is put at a BFF layer.
(5) When third interaction outside the intelligent medical cloud ecology is needed in business, the interaction is placed in a BFF layer, so that only necessary information can be exposed to a third party, and the access of the third party is convenient to control.
As an example, communication in a smart medical cloud ecology employs an API interface based on RPC (remote product call) remote calls that employs a Dubbo framework, a high-performance, lightweight, open source Java RPC framework that provides three core capabilities: interface-oriented remote method calling, intelligent fault tolerance and load balancing, and automatic service registration and discovery. For the system outside the intelligent medical cloud ecology, data interaction is performed through an ESB (Enterprise Service bus) information platform.
Therefore, the above step S101 can achieve the following objectives: each micro service depends on the interface, independent development is supported among the micro services, and the development efficiency is high; the micro-service can be independently compiled, and the compiling time is short; based on the dependence of the service interface, only relevant services need to be tested, and the test regression period is short; only relevant services need to be developed, full testing is not needed, and the requirement change can be quickly met. Therefore, the micro-service can be developed independently, the cost is low, and the development experience can be improved by micro-service.
In the step S102, in the deployment phase, automatic deployment is performed, and the target service is deployed to the corresponding kubernets environment by one key to operate. For example, a tested code is manufactured into a Docker mirror image in advance by using a platform automation packaging function, and is uploaded to a mirror image warehouse of a cloud platform end, and then the cloud platform end sends an application program installation package based on a micro-service architecture to a medical end under the condition that the cloud platform end receives an installation request sent by the medical end, so that the medical end automatically completes installation and deployment.
Further, in the embodiment of the application, the change of the micro-service version is detected to the cloud platform end at regular time, and when the micro-service version is updated, the cloud platform end sends a change notification to the operation and maintenance platform of the medical end; and the cloud platform end sends the container mirror image installation package to the medical end under the condition of receiving the update request sent by the operation and maintenance platform, and the medical end automatically updates the version.
Furthermore, high-availability enterprise-level architecture design is adopted to reinforce open sources Kubernets and Dockers, support automatic installation and deployment of clusters, support high availability of clusters, support cluster split prevention, support multi-level mirror image libraries and support unified monitoring. For example, in terms of security, high isolation of resources is supported and services are highly available. And the container engine runs in an exclusive cloud server instance, so that high isolation level is realized, and a highly safe and reliable application program is constructed. In addition, the container engine adopts a distributed service architecture to realize automatic recovery and rapid migration of service failures; and the distributed storage combined with the state service realizes the safety and high availability of the service and data. From the aspect of on-demand deployment, the deployment and scheduling of multiple project spaces and multiple instances are supported. And in the operation and maintenance stage, monitoring various indexes applied in the production environment, and early warning the abnormal state of application in real time. The system has a continuous CI/CD integration and continuous deployment function, and helps development and operation and maintenance personnel to complete code construction, test and deployment.
Furthermore, the method also comprises a configuration management step, the configuration center is used for uniformly managing the related configuration files on each medical terminal, one medical terminal does not need to be logged in to change the configuration, and the operation and maintenance working efficiency is improved.
Further, the method also comprises a log analysis step, wherein the log format comprises the following steps: time of log record, log level, micro-service identifier, thread name, log class and row number, distributed trace call chain Id, log content, etc.; the log classification comprises a system log, a service log and a container log, wherein the system log: only outputting to files, and logs output by a development framework and a development component in the micro-service operation process, such as Spring Boot startup logs, Mybatis exception logs, ZooKeeper connection logs and the like; service log: the log output by the service code in the micro service operation process is only output to the file, such as a user login log, a service operation log and the like, and if the service code is under a cc.ewell packet, the log output under the cc.ewell packet can be limited; container log: the logs printed on the container console are as simplified as possible, the production environment only allows the ERROR level logs to be printed, the performance can be improved, and repeated writing is avoided. In the embodiment of the application, the original logs scattered on each medical terminal are uniformly stored, the logs are subjected to relevant analysis, and the operation condition of the service system is known. Optionally, a link log tracking system is included.
Further, the method comprises a monitoring and alarming step, wherein the operation condition is monitored, if the alarm is triggered, further adjustment measures can be taken, for example, when a patient has a peak visit in the morning, a prescription request of a doctor is increased sharply, the cloud platform end monitors that the calling amount of the prescription service is increased, the CPU and the memory consumed by the container exceed 90%, and then the container copy is automatically expanded for the prescription service, so that the calling pressure is distributed to a new container copy.
Therefore, the micro-service architecture platform of the embodiment of the present application can perform unified management and scheduling on container processes distributed on multiple servers (i.e., medical terminals), and can uniformly arrange the server on which the container should be started to operate by monitoring and calculating, so as to achieve the following objectives: arranging containers across multiple hosts; hardware is utilized more fully, and resources required by running enterprise applications are acquired to the maximum extent; the deployment and the update of the application are effectively controlled, and automatic operation is realized; mounting and adding storage for running stateful applications; quickly expanding containerized applications and resources thereof as needed; performing declarative management on the service to ensure that the deployed application runs in a deployment mode all the time; with automatic layout, automatic restart, automatic copy, and automatic expansion functions, application health checks and self-healing are performed.
To sum up, the embodiment of the application can achieve the following beneficial effects:
(1) after the services are split, each micro service can be independently developed, tested and deployed in parallel, the delivery efficiency is improved, the updating speed of the product is higher, the user experience is better, and the larger the code scale is, the more obvious the advantages of the micro service are.
(2) The micro-services run independently, the fault range is effectively controlled and the architecture becomes simpler and more reliable by process isolation, services can be divided according to the importance degree of the services, and core services are divided into independent services, so that effective fault isolation can be kept from a database to the services, and further, the stability is kept.
(3) The micro-service framework has higher overall usability due to the fact that the fault range is effectively isolated, and the influence of one point of fault on the whole is reduced.
(4) Because the granularity of the micro-service is smaller, the influence surface of the architecture evolution is smaller, various problems caused by large-scale reconstruction do not exist, and the micro-service architecture is more friendly to the architecture evolution.
(5) The larger the team scale is, the lower the communication efficiency is, and the micro-service architecture constructs a full-function team according to the service and puts down the power, so that a decision bottleneck point cannot occur, the communication scale is reduced, and the communication efficiency is improved.
(6) If a certain service needs an independent technology stack, the method can be realized in a service division and interface integration mode, and the technology stack is flexible to select.
(7) The micro-service architecture can be expanded by taking service as granularity according to the requirement of the service on resources, and accords with Y-axis expansion in the AKF expansion cube, while the single architecture can only be expanded integrally and can only realize X-axis expansion in the AKF expansion cube.
(8) The micro-service architecture can realize sharing and reusing through the interface by taking the service as granularity, so the reusability is high.
(9) The micro-service architecture can resolve a complex problem into a simple small problem more easily by resolving the service into more services, and the service boundary is clearer.
(10) The micro-service architecture independently evolves by taking service as granularity, a team has more autonomous decision-making rights and more trial and error opportunities, and innovation is facilitated.
It should be noted that, for specific examples in this embodiment, reference may be made to examples described in the foregoing embodiments and optional implementations, and details of this embodiment are not described herein again.
In addition, in combination with the cloud-based smart medical cloud ecological service method in the above embodiments, the embodiments of the present application may provide a storage medium to implement. The storage medium having stored thereon a computer program; when being executed by a processor, the computer program realizes any one of the cloud-based smart medical cloud ecological service methods in the embodiments.
An embodiment of the present application also provides an electronic device, which may be a terminal. The electronic device comprises a processor, a memory, a network interface, a display screen and an input device which are connected through a system bus. Wherein the processor of the electronic device is configured to provide computing and control capabilities. The memory of the electronic equipment comprises a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of an operating system and computer programs in the non-volatile storage medium. The network interface of the electronic device is used for connecting and communicating with an external terminal through a network. The computer program is executed by a processor to realize a cloud-native based intelligent medical cloud ecological service method. The display screen of the electronic equipment can be a liquid crystal display screen or an electronic ink display screen, and the input device of the electronic equipment can be a touch layer covered on the display screen, a key, a track ball or a touch pad arranged on the shell of the electronic equipment, an external keyboard, a touch pad or a mouse and the like.
In one embodiment, fig. 3 is a schematic diagram of an internal structure of an electronic device according to an embodiment of the present application, and as shown in fig. 3, there is provided an electronic device, which may be a server, and its internal structure diagram may be as shown in fig. 3. The electronic device comprises a processor, a network interface, an internal memory and a non-volatile memory connected by an internal bus, wherein the non-volatile memory stores an operating system, a computer program and a database. The processor is used for providing computing and control capabilities, the network interface is used for communicating with an external terminal through network connection, the internal memory is used for providing an environment for an operating system and running of a computer program, the computer program is executed by the processor to realize a cloud-native-based intelligent medical cloud ecological service method, and the database is used for storing data.
Those skilled in the art will appreciate that the architecture shown in fig. 3 is a block diagram of only a portion of the architecture associated with the subject application, and does not constitute a limitation on the electronic devices to which the subject application may be applied, and that a particular electronic device may include more or less components than those shown, or may combine certain components, or have a different arrangement of components.
It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by hardware instructions of a computer program, which can be stored in a non-volatile computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. Any reference to memory, storage, database, or other medium used in the embodiments provided herein may include non-volatile and/or volatile memory, among others. Non-volatile memory can include read-only memory (ROM), Programmable ROM (PROM), Electrically Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDRSDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), Rambus Direct RAM (RDRAM), direct bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).
It should be understood by those skilled in the art that various features of the above-described embodiments can be combined in any combination, and for the sake of brevity, all possible combinations of features in the above-described embodiments are not described in detail, but rather, all combinations of features which are not inconsistent with each other should be construed as being within the scope of the present disclosure.
The above-mentioned embodiments only express several embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the concept of the present application, which falls within the scope of protection of the present application. Therefore, the protection scope of the present patent shall be subject to the appended claims.
Claims (10)
1. A smart medical cloud ecological service method based on cloud protogenesis is applied to a cloud platform end, and the method comprises the following steps:
splitting the service into a plurality of micro services, and constructing a micro service architecture;
under the condition of receiving an installation request sent by a medical end, sending an application program installation package based on the micro-service architecture to the medical end so that the medical end automatically completes installation and deployment;
and when the patient end and/or the doctor end performs service interaction with the medical end, operating the service container and performing scheduling management through Kubernetes.
2. The method of claim 1, wherein the service interaction between the patient end and/or the doctor end and the medical end comprises:
and the patient end and/or the doctor end performs service interaction with a service layer of the medical end through an access layer gateway, wherein the service layer comprises a BFF layer, and the BFF layer is used for aggregating backend services, controlling access authority and caching application data.
3. The method of claim 2, further comprising:
interacting with a third party outside the smart medical cloud ecology through the BFF layer.
4. The method of claim 1, wherein the service container supports at least one of HIS, EMR, PACS, LIS, and hand anesthesia systems.
5. The method of claim 1, wherein communication is performed in the smart medical cloud ecosystem using an API interface based on RPC remote calls, wherein the RPC employs a Dubbo framework.
6. The method of claim 1, wherein after the medical end automatically completes an installation deployment, the method further comprises:
when the micro service version is updated, sending a change notice to an operation and maintenance platform of the medical end;
and under the condition of receiving an updating request sent by the operation and maintenance platform, sending a container mirror image installation package to the medical terminal so as to enable the medical terminal to be automatically updated.
7. The method of claim 1, further comprising:
uniformly managing the configuration files on each medical terminal, and uniformly storing the service logs;
and analyzing the service log, knowing the operation condition of the service system and monitoring the operation condition.
8. The method of claim 1, wherein the content of the service interaction between the patient side and the business layer of the medical side comprises at least one of self-service card handling, appointment registration, online inquiry, online consultation, online party continuation, report viewing, medical record viewing, expense settlement, message notification and satisfaction evaluation;
the content of service interaction between the doctor end and the service layer of the medical end comprises at least one of cloud diagnosis, on-line consultation, electronic prescription, third-party pharmacy, special orientation, journey consultation, MDT service, on-line education and on-line follow-up visit.
9. An electronic device comprising a memory and a processor, wherein the memory has stored therein a computer program, and wherein the processor is arranged to execute the computer program to perform the method of any of claims 1 to 8.
10. A storage medium, in which a computer program is stored, wherein the computer program is arranged to perform the method of any one of claims 1 to 8 when executed.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111044182.9A CN113921130A (en) | 2021-09-07 | 2021-09-07 | Cloud-native-based smart medical cloud ecological service method, equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111044182.9A CN113921130A (en) | 2021-09-07 | 2021-09-07 | Cloud-native-based smart medical cloud ecological service method, equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113921130A true CN113921130A (en) | 2022-01-11 |
Family
ID=79234027
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111044182.9A Pending CN113921130A (en) | 2021-09-07 | 2021-09-07 | Cloud-native-based smart medical cloud ecological service method, equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113921130A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114928633A (en) * | 2022-05-16 | 2022-08-19 | 江苏赞奇科技股份有限公司 | Efficient control method and system based on complex cloud application environment |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107248986A (en) * | 2017-06-08 | 2017-10-13 | 医惠科技有限公司 | A kind of service tray method |
| CN110086853A (en) * | 2019-03-28 | 2019-08-02 | 浙江明度智控科技有限公司 | A kind of industry Internet of Things information visualization methods, server and storage medium |
| CN110543537A (en) * | 2019-08-22 | 2019-12-06 | 广东省城乡规划设计研究院 | Intelligent planning space-time cloud GIS platform based on Docker container and micro-service architecture |
| CN110704164A (en) * | 2019-09-30 | 2020-01-17 | 珠海市新德汇信息技术有限公司 | Cloud native application platform construction method based on Kubernetes technology |
| CN111080256A (en) * | 2019-12-16 | 2020-04-28 | 广东珠江智联信息科技股份有限公司 | Internet medical platform framework |
| CN111681752A (en) * | 2020-05-11 | 2020-09-18 | 纳里健康科技有限公司 | Doctor conjuncted diagnosis and treatment system based on cloud platform |
| CN112187513A (en) * | 2020-08-31 | 2021-01-05 | 四川羽影医疗科技有限公司 | Medical Internet of things cloud platform method and system based on big data and storage medium |
| CN113259447A (en) * | 2021-05-26 | 2021-08-13 | 中国电子信息产业集团有限公司第六研究所 | Cloud platform deployment method and device, electronic equipment and storage medium |
-
2021
- 2021-09-07 CN CN202111044182.9A patent/CN113921130A/en active Pending
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107248986A (en) * | 2017-06-08 | 2017-10-13 | 医惠科技有限公司 | A kind of service tray method |
| CN110086853A (en) * | 2019-03-28 | 2019-08-02 | 浙江明度智控科技有限公司 | A kind of industry Internet of Things information visualization methods, server and storage medium |
| CN110543537A (en) * | 2019-08-22 | 2019-12-06 | 广东省城乡规划设计研究院 | Intelligent planning space-time cloud GIS platform based on Docker container and micro-service architecture |
| CN110704164A (en) * | 2019-09-30 | 2020-01-17 | 珠海市新德汇信息技术有限公司 | Cloud native application platform construction method based on Kubernetes technology |
| CN111080256A (en) * | 2019-12-16 | 2020-04-28 | 广东珠江智联信息科技股份有限公司 | Internet medical platform framework |
| CN111681752A (en) * | 2020-05-11 | 2020-09-18 | 纳里健康科技有限公司 | Doctor conjuncted diagnosis and treatment system based on cloud platform |
| CN112187513A (en) * | 2020-08-31 | 2021-01-05 | 四川羽影医疗科技有限公司 | Medical Internet of things cloud platform method and system based on big data and storage medium |
| CN113259447A (en) * | 2021-05-26 | 2021-08-13 | 中国电子信息产业集团有限公司第六研究所 | Cloud platform deployment method and device, electronic equipment and storage medium |
Non-Patent Citations (4)
| Title |
|---|
| 冯志勇;徐砚伟;薛霄;陈世展;: "微服务技术发展的现状与展望", 计算机研究与发展, no. 05, 15 May 2020 (2020-05-15), pages 209 - 228 * |
| 刘辉军;刘培锋;邱钰锋;戴桂灶;: "基于开源框架及容器技术的微服务架构研究", 电力信息与通信技术, no. 06, 15 June 2018 (2018-06-15), pages 94 - 98 * |
| 李晓明;黄慧;应毅;吴德;: "基于微服务架构的智能医疗平台设计与开发", 信息与电脑(理论版), no. 24, 25 December 2019 (2019-12-25), pages 60 - 62 * |
| 陆钢;陈长怡;黄泽龙;黄泽源;: "面向云网融合的智能云原生架构和关键技术研究", 电信科学, no. 09, 20 September 2020 (2020-09-20), pages 71 - 78 * |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114928633A (en) * | 2022-05-16 | 2022-08-19 | 江苏赞奇科技股份有限公司 | Efficient control method and system based on complex cloud application environment |
| CN114928633B (en) * | 2022-05-16 | 2024-04-16 | 江苏赞奇科技股份有限公司 | Efficient control method and system based on complex cloud application environment |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20190318240A1 (en) | Training machine learning models in distributed computing systems | |
| US8751573B2 (en) | Cloud-processing management with a landscape directory | |
| US10999407B1 (en) | Service group interaction management | |
| US20060282886A1 (en) | Service oriented security device management network | |
| US20080140759A1 (en) | Dynamic service-oriented architecture system configuration and proxy object generation server architecture and methods | |
| US20080140857A1 (en) | Service-oriented architecture and methods for direct invocation of services utilizing a service requestor invocation framework | |
| Agirre et al. | QoS aware middleware support for dynamically reconfigurable component based IoT applications | |
| US11169787B2 (en) | Software acceleration platform for supporting decomposed, on-demand network services | |
| CN108700922B (en) | Data center management | |
| CN113204353B (en) | Big data platform assembly deployment method and device | |
| Agarwal et al. | Open service platforms for IoT | |
| Lakhani et al. | Fault administration by load balancing in distributed SDN controller: A review | |
| CN113921130A (en) | Cloud-native-based smart medical cloud ecological service method, equipment and storage medium | |
| US20220357940A1 (en) | Proactive Notifications for Robotic Process Automation | |
| CN108700923B (en) | Data center management | |
| US11777810B2 (en) | Status sharing in a resilience framework | |
| CN112565340B (en) | Service scheduling method, device, computer system and medium for distributed application | |
| Stack et al. | Self-healing in a decentralised cloud management system | |
| CN116954810A (en) | Method, system, storage medium and program product for creating container application instance | |
| US10897463B2 (en) | Managing and securing manageable resources in stateless web server architecture using servlet filters | |
| US9841929B1 (en) | Distributed system software infrastructure | |
| Mezghani et al. | DRAAS: dynamically reconfigurable architecture for autonomic services | |
| Passini et al. | A Framework to Support the Development of Self-adaptive Service-oriented Mobile Applications. | |
| US11909818B2 (en) | Reaching a quorum with a number of master nodes | |
| Borges | 5GLAN: Local Area Networks Based on 5G Technologies for Mission Critical Services |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |