软件架构选型
目的
构建统一的软件开发平台（文档后面以“平台”简称），新开发的软件项目或优化重构的项目都基于此平台，让研发工程师更多的精力关注业务功能的开发，提高开发效率，增强系统稳定性功与可维护性，节省维护成本。平台定位于技术层面，为统一公司内相关产品研发和项目实施使用的技术架构，有效提高统一技术支持力度，形成持续的技术积累手段，提升技术人员的利用率并降低对人员的依赖性，最终提升软件的规模化、流水线式的生产能力，为打造精品化的软件产品提供技术支撑。
统一开发平台不涉及业务，属软件架构顶层设计，从而保证各产品间相互独立，互不影响，仅共用平台。平台可以根据具体需求定制应用程序，满足企业持续改进的业务应用需求。
设计原则
平台建设采用业界成熟的解决方案，如无特殊要求，平台所依赖第三方组件使用主流的开源组件。平台搭建基于如下设计原则：
前瞻性：以促进业务发展为指导原则，确保平台成熟稳定的同时放眼未来迎合发展。
兼容性：平台为开放式、标准化平台，支持主流开发语言的接入，如JAVA、DOTNET、PYTHON等；支持不同数据库的接入，如Oracle 、SQL Server、MySQL、PostgreSQL；系统能运行于Windows、Linux内核的操作系统平台；
可扩展性：采用灵活、开放的模块化设计为系统扩展、升级及可预见的管理模式的改变留有余地。
可靠性：多维度保障平台的正常运转与数据安全可靠。
可维护性：采用标准、轻量级的交互接口，各子系统相互独立，在出现故障时，能快捷的处理。
安全性：平台对数据的存储和访问提供有效的安全措施，防止受到恶意攻击，访问调用有痕且追溯可查。
建设方案
总体思路
平台的建设采用分层设计，每一层都有清晰的角色和分工，不需要知道其它层的细节，层与层之间通过接口通信。将应用系统划分为若干层，每一层只解决问题的一部分，通过各层的协作提供整体解决方案，大的问题被分解为一系列相对独立的子问题，局部化在每一层中，有效的降低了单个问题的规模和复杂度，实现复杂系统的第一步也是最为关键的一步分解。一般情况下大体分为五层，结构如下：
Ø 第一层：操作系统运行环境
平台运行依赖的操作系统、运行环境，如Windows系统、Linux系统，可部署于自建机房、云虚拟主机，方式及其灵活，根据需求而定。
Ø 第二层：数据存储层
存储用户的信息、系统运行规则信息、配置信息、业务数据，为系统的运转提供数据来源。数据是整个平台的核心，需要保证其安全性。数据存储采用关系型数据库，如MySQL，同时特殊业务场景可使用NoSQL技术来满足业务需求，如MongDB。
Ø 第三层：基础组件层
封装与业务无关的基础功能，如文件操作、数据库读写、配置管理、鉴权、加密与解密、消息管理、推送、缓存、定时任务等。
Ø 第四层：业务平台层
具体的业务功能，根据团队现状采用不同的开发语言。
Ø 第五层：展现层
用户接口，业务功能的具体展示，载体形式多样化，如手机、Web、手持机、传统桌面应用。
分层架构一般具有良好的可扩展性，为应用系统的演化增长提供了一个灵活的框架，增加新的功能时，无须对现有的代码做修改，业务逻辑可以得到最大限度的重用。同时，层与层之间可以方便地插入新的层来扩展应用。分层架构易于维护，在对系统进行分解后，不同的功能被封装在不同的层中，层与层之间的耦合显著降低，因此在修改某个层的代码时，只要不涉及层与层之间的接口，就不会对其他层造成严重影响。
实现分层架构的方式有很多种，如微服务架构、单体架构、事件驱动架构、SOA架构等，以相对主流的微服务架构、单体架构为例，详细介绍其优缺点。
方案一：微服务软件架构
微服务是系统架构上的一种设计风格，它的主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务间通过基于HTTP的RESTful API进行通信协作。被拆分成的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建，并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制。由于有了轻量级的通信协作基础，所以这些微服务可以使用不同的语言编写。
实现微服务目前主流的有两种方式，阿里的Dubbo与Spring Cloud，由于Dubbo只解决了微服务中的部分问题，不是一个综合性的解决方案，所以平台以SpringCloud为基础。Spring Cloud为微服务架构中涉及的配置管理、服务治理、断路器、智能路由、分布式会话和集群管理等提供了一种简单的开发方式。架构示意图如下：
说明：
Ø 服务注册中心
服务治理组件，包含服务注册中心、服务注册与发现机制的实现。系统的核心组件，业务模块、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层模型，表示层、业务层与持久层，各层分工不同。一个典型的单体应用就是将所有的业务场景的表示层、业务层和持久层放在一个工程中，最终经过编译、打包，部署在一台服务器上。架构示意如下：
说明：
Ø 所有业务共享同一数据库；
Ø 所有业务部署在同一进程，可部署多份实例，实现负载均衡；
Ø 针对访问量大的场景，使用Nginx组实现分流。
单体架构的优劣势都很明显。
单体架构方案的优点：
Ø 开发简单直接，集中式管理；
Ø 基本不会重复开发；
Ø 功能都在本地，没有分布式的管理开销和调用开销。
单体架构方案的缺点：
Ø 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断；
Ø 代码维护难：代码功能耦合在一起，新人不知道何从下手；
Ø 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长；
Ø 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉；
Ø 扩展性不够：无法满足高并发情况下的业务需求。
针对目前公司现状的统一软件架构平台方案
上面介绍了微服务架构与单体架构两种架构方式，分别介绍了其优劣点，两种方式都做过技术预研，都具备可实施性。我们目前软件团队有JAVA与DOTNET开发人员，有Web类、手机类、桌面类、手持机类产品，各种应用的访问量有限，基于这个现状，考虑简化微服务架构，规避其缺点，发挥其优点，也方便向最终的微服务架构演进。
说明：
Ø 数据库统一部署，所有业务访问统一数据源，规避了数据库分库的事务问题；
Ø 业务模块不变，支持JAVA、DOTNET平台；
Ø API网关、服务注册中心不采用集群部署，减少部署难度；
Ø API网关做客户端的负载均衡，移除Nginx层，减少部署难度；
Ø 客户端直连网关。