失眠网 > 低代码开发平台如何支撑微服务/云原生架构

低代码开发平台如何支撑微服务/云原生架构

时间：2018-08-07 13:05:50

目前“低代码”、“微服务”这两个IT词汇很流行，国内主流的低代码开发平台很多：宜搭、简道云、明道云、云程、氚云、伙伴云、道一云、JEPaaS、华炎魔方、搭搭云、JeecgBoot 、RuoYi等。这些低代码开发平台是否都支持微服务或云原生架构，需要从几个方面进行考量。

一、什么是微服务架构？

目前业界普遍引用马丁富勒对微服务的定义：

/articles/microservices.html

The term “Microservice Architecture” has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间胡亮协调、互相配合，为用户提供最终价值。在微服务架构中，服务与服务之间通信时，通常是通过轻量级的通信机制，实现彼此间的互通互联、互相协作。所谓轻量级通信机制，通常是指与语言无关、与平台无关的这类协议。通过轻量级通信机制，使服务与服务之间的协作变得简单、标准化。

关键特性：横向前后端分离、纵向切分微服务（包括数据库）

实际上微服务核心问题是分工、协作和治理。微服务分工即如何拆分微服务，每个服务如何独立运行，微服务协作是指服务间如何通讯，这两个问题是低代码开发平台要解决的，云程低代码开发平台完全遵照云原生十二要素法，基于云程平台开发的应用自然满足微服务架构。微服务治理一般都独立的产品，比如开源Istio、华为CSE、阿里ASM等，微服务治理可以与开发平台解耦。

二、微服务对应用程序有什么要求？

微服务的本质是敏捷、弹性、灵活、容错，不是所有的应用程序都可以拆分微服务，业界提出了云原生十二要素法，满足这些规则即满足了微服务架构要求。云程低代码开发平台完全遵照云原生十二要素法，基于云程平台开发的应用自然满足微服务架构。

基准代码：一份基准代码，多份部署。基准代码和应用之间总是保持一一对应的关系。所有部署的基准代码相同，但每份部署可以使用其不同的版本。依赖：显示声明依赖关系。应用程序一定通过依赖清单，确切地声明所有依赖项。配置：在环境中存储配置。将应用的配置存储于环境变量中。环境变量可以非常方便地在不同的部署间做修改，却不动一行代码。后端服务：不区分本地和远端服务。不要把服务打包在应用中，通过绑定或是DNS寻址。构建、发布、运行：严格区分构建、发布、运行这三个步骤，不要在运行中去改配置。进程无状态：应用的进程必须无状态且无共享，Session中的数据应该保存在诸如Memcached或Redis缓存中。目的是容器化部署可以水平扩展。端口绑定：通过端口绑定提供服务。应用完全自我加载而不依赖于任何网络服务器就可以创建一个面向网络的服务。并发：通过进程模型进行扩展，开发人员可以运用这个模型去设计应用架构，将不同的工作分配给不同的进程类型，每个进程均可以并发，可以弹性伸缩。易销毁性：快速启动和优雅终止可最大化健壮性。应用的进程是可销毁的，意思是说它们可以瞬间开启或停止。无状态是前提条件。开发环境与线上环境等价：尽可能保持开发、预发布、线上环境相同。应用想要做到持续部署就必须缩小本地与线上差异。日志：把日志当作事件流。应用本身考虑存储自己的输出流。不应该试图去写或者管理日志文件。管理进程：基于某个发布版本运行。后台管理代码应该随其他应用程序代码一起发布。