软件架构选型

目的

构建统一的软件开发平台（文档后面以“平台”简称），新开发的软件项目或优化重构的项目都基于此平台，让研发工程师更多的精力关注业务功能的开发，提高开发效率，增强系统稳定性功与可维护性，节省维护成本。平台定位于技术层面，为统一公司内相关产品研发和项目实施使用的技术架构，有效提高统一技术支持力度，形成持续的技术积累手段，提升技术人员的利用率并降低对人员的依赖性，最终提升软件的规模化、流水线式的生产能力，为打造精品化的软件产品提供技术支撑。

统一开发平台不涉及业务，属软件架构顶层设计，从而保证各产品间相互独立，互不影响，仅共用平台。平台可以根据具体需求定制应用程序，满足企业持续改进的业务应用需求。

设计原则

       平台建设采用业界成熟的解决方案，如无特殊要求，平台所依赖第三方组件使用主流的开源组件。平台搭建基于如下设计原则：

       前瞻性：以促进业务发展为指导原则，确保平台成熟稳定的同时放眼未来迎合发展。

       兼容性：平台为开放式、标准化平台，支持主流开发语言的接入，如JAVA、DOTNET、PYTHON等；支持不同数据库的接入，如Oracle 、SQL Server、MySQL、PostgreSQL；系统能运行于Windows、Linux内核的操作系统平台；

       可扩展性：采用灵活、开放的模块化设计为系统扩展、升级及可预见的管理模式的改变留有余地。

       可靠性：多维度保障平台的正常运转与数据安全可靠。

       可维护性：采用标准、轻量级的交互接口，各子系统相互独立，在出现故障时，能快捷的处理。

       安全性：平台对数据的存储和访问提供有效的安全措施，防止受到恶意攻击，访问调用有痕且追溯可查。

建设方案

总体思路

       平台的建设采用分层设计，每一层都有清晰的角色和分工，不需要知道其它层的细节，层与层之间通过接口通信。将应用系统划分为若干层，每一层只解决问题的一部分，通过各层的协作提供整体解决方案，大的问题被分解为一系列相对独立的子问题，局部化在每一层中，有效的降低了单个问题的规模和复杂度，实现复杂系统的第一步也是最为关键的一步分解。一般情况下大体分为五层，结构如下：

说明：

?  服务注册中心

服务治理组件，包含服务注册中心、服务注册与发现机制的实现。系统的核心组件，业务模块、API 关、配置服务等都需要注册到服务中心，一般情况下服务注册中心会部署成集群，满足高可用条件。

?  API 关

API 关主要实现请求路由、负载均衡、校验过滤等功能。需要注册到服务治理中心，根据业务场景，可部署层集群，防止单点故障。

?  业务模块

业务模块，有独立的数据库，支持大部分语言实现，如JAVA、DOTNET，业务模块必须要注册到服务治理中心，便于扩展，如发现某个业务模块访问压力较大，可将其复制一份，启动进程，注册到服务中心，这样就自动实现了服务端的负载均衡。在实际应用过程中要尽量避免业务模块间的通信，如不可避免，采用Fegin声明式方式访问。

?  负载均衡

针对访问量大的场景，起到分流的作用，分流到API 关。比较成熟的解决方案是采用Nginx组件，为了防止Nginx单点故障，Nginx做主备切换。

?  客户端

使用终端，如手机APP、Web等通过HTTP接口访问业务接口，通过DNS轮询机制将请求分发到Nginx、Nginx在分发到API 关、API 关在路由到业务模块，处理完业务逻辑后，将结果返回到前端。

通过以上的说明，对微服务架构有了基本了解，从架构图上可看到，微服务也带来新的挑战，如要面对服务增多、接口一致性管理复杂的问题。

微服务架构方案的优点：

l  通过分解单体式应用为多个服务方法解决了复杂性问题。在功能不变的情况下，应用被分解为多个可管理的分支或服务，每个服务都有一个用HTTP API定义清楚的边界，微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案，由此，单个服务很容易开发、理解和维护。

l  微服务架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术，提供API服务。为试图避免混乱，一般只提供一到二种技术选择。然后，这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术，他们可以选择现在的技术。甚至于，因为服务都是相对简单，即使用现在技术重写以前代码也不是很困难的事情。

l  微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响，这种改变可以加快部署速度，微服务架构模式使得持续化部署成为可能。

l  微服务架构模式使得每个服务独立扩展。可以根据每个服务的规模来部署满足需求的规模。

微服务方案的缺点：

l  运维的挑战：在微服务架构中，运维人员需要维护的进程数量会大大增加。有条不紊地将这些进程编排和组织起来不是一件容易的事，传统的运维人员往往很难适应这样的变化。

l  接口的一致性：虽然拆分了服务，但业务逻辑上的依赖并不会消除，只是从单体应用中的代码依赖变为了服务间的通信依赖。当对原有接口进行了一些修改，交互方需要协调这样的改变来进行发布，以保证接口的正确调用。

l  分布式的复杂性：由于拆分后的各个微服务都是独立部署并运行在各自的进程内，它们只能通过通信来进行协作，所以分布式环境都将是微服务架构系统设计要考虑的重要因素，比如 络延时、分布式事物、异步消息等。

方案二：传统单体架构

       单体架构一般是指经典的3层模型，表示层、业务层与持久层，各层分工不同。一个典型的单体应用就是将所有的业务场景的表示层、业务层和持久层放在一个工程中，最终经过编译、打包，部署在一台服务器上。架构示意如下：

说明：

?  数据库统一部署，所有业务访问统一数据源，规避了数据库分库的事务问题；

?  业务模块不变，支持JAVA、DOTNET平台；

?  API 关、服务注册中心不采用集群部署，减少部署难度；

?  API 关做客户端的负载均衡，移除Nginx层，减少部署难度；

?  客户端直连 关。

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8608 人正在系统学习中