如何进行系统架构以及技术选型（漫谈IT系统架构选型）

什么是it系统架构？浅谈IT系统架构的选择。

1、IT架构和项目管理的基本理论

自19世纪40年代被引入企业以来，信息化一直高速发展。在不到70年的时间里，理论发展非常迅速，入门门槛已经很低。

软件工程的快速发展，尤其是多项目管理作为一门学科的理论，有点不可思议，因为它借鉴了一个成熟的体系架构。欧美成熟的架构理论和体系很快被计算机科学家复制并改编到软件领域。

说白了，建筑就是盖房子。根据不同的场景，不同的需求，需要搭建一个简易的小屋，两层的房子。市区人口密集，多为20至50层的小高层和高层建筑。金融中心会有超高层地标；

对于简易小屋来说，通常是把要盖房子的空地整平。房子奎略高，周边略低，方便排水。然后把房子的地基挖出来，直接建一个石头水泥做的基座。适合临时使用或储存；

对于house，用户一般在家里使用，要求稳定，使用寿命长，但规模小，成本低。通常房屋基础开挖在平基上，铺设钢筋混凝土基础和框架，填充砌体覆盖屋顶，隔音、通风、保暖、防雨，并根据日常使用划分功能区；

小高层建筑就复杂多了，因为规模大，层高高，造价高，规模大，周期长，涉及材料多，人员多，对人员的要求更高，普通建筑的施工人员基本上是不能胜任的，所以需要先规划设计蓝图，再计算成本，根据施工阶段规划材料进场的时序和相应工程师的介入；蓝图成本核算完成后，就要先打桩了。普通地梁基础can 不能承受高层建筑，需要勘测地下土体结构的受力情况，然后确定地桩深度，再深挖地桩，做坚固的地梁。这一块铺好后，直接用钢筋混凝土浇筑整个框架。，房子的功能区用空心砖分割；

高层和超高层建筑更复杂。除了小高层的所有因素，还需要考虑各楼层通道、消防、水、气、电、周边交通等配套因素。蓝图规划也应该考虑这些因素。例如，消防走道通常有两个通道，每10层左右有一个防火层。高层建筑供水需要加压，电梯使用高速电梯且维修频率较高，基础下桩较深。

任何一个开发商为了获得更多的利润，自然会想方设法规范自己的整体操作流程，所以可以看出，万科、花半里、鸿荣园等开发商在重新设计和交付产品时，对多个项目的理解程度是非常高的，即他们已经规范了所有的规划架构，只需要在新项目中修改一些细节，省去了全新规划建设带来的时间、成本和风险。

根据公司的规模和形式。企业对信息化的需求就像人对信息的需求一样。对建筑的需求。暂时的需求是一个可以遮阳、挡雨、挡风的简易小屋。如果业务不 不太依赖信息化，可以用相应的常规系统，比如面向产品的家庭主妇。如果业内没有成熟的软件，定制一个；如果公司 s业务规模大，产品类型复杂，业务流程长，需要按照一栋高层建筑，甚至高层建筑群来规划；比如一个大型的集团公司(高层建筑综合体)，他们的结构底部必须足够厚，所有可复用的功能都要建成一个构件库(桩、内部钢架、门窗，图案按类别统一)。，由于规模较大，必须有多个出入口，甚至人车按需划分(系统内外对接接口，系统集成)，小区内部必须有多个区域划分和管理。当这些思想被借鉴时，自然就导致了IT设计和项目管理理念的高度相似。

一个信息系统的底层建设，自然可以脱离过去的经验，组织成一个高标准、完美集成的框架。这样应用到相应规模的软件研发中，自然会节省时间和人力，也不需要对过去使用的模块(比如对接支付宝、微信、钉钉、权益模块、消息模块)进行二次开发。在一个完善的框架中，开发者只需要像填空一样对具体的业务逻辑进行编码，前端UI就像一个装璜师一样，可以根据开发者或者客户的需求进行UI对接业务逻辑，从而快速开发出应用系统。

2.关于软件框架。

有了好的框架，开发软件就会事半功倍。近年来，从架构到框架，软件人的追求从未停止。SOA，RESTful，微服务，低代码..............

(1)软件框架

让 让我们从最近流行的低代码平台开始吧！

从10年前接触低码平台到现在，低码平台的发展迭代了很多类型。简单分类为以下浓度

a)通过拖动和设置生成数据字典和函数表单。

b)拖动生成数据字典和表单，设计好基础函数后，一键生成整个基础函数的源代码；

c)只能生成首页的代码；不支持后端。

d)拖动微服务架构代码支架的前端，生成首页代码；这其中的本质不是一个低代码生成器，而是一个强大的技术框架前端代码生成工具。

之一个入门门槛低，限制多，很难离开这个开发平台。比如多个子系统只能登上这个低代码平台。逻辑太复杂的地方，需要开发平台支持，不能支持的只能在数据库里写存储过程实现。数据量大效率低，集成其他组件特别是行业特色的组件很麻烦，系统集成也很麻烦，界面难看，生成。

B/S界面不灵活；，更大的问题就是开放性不够，只能在现有平台提供的功能里设计和开发，且数据量并发很低，不适用与大型平台和并发量较大的系统；金蝶的BOS也属于这种，由于限制太多，只能作为金蝶ERP扩展功能使用；若想利用低代码平台开发复杂功能或整个模块，则较为困难；

第二种则相对较为灵活，其本质是一个代码生成器，呢，又可以把基本的功能提前生成出来并内置好部分公用组件，可扩展性较高；

第三种在互联网行业用得较多，因为他们已经有了成熟的数据中台，所有的业务逻辑大部分都是通过中台抽取出来再简单组合即可，这样，大部分的工作量就集中在前端；所以比较适用于业务比较成熟且系统成熟度较高的企业；

一种比较适用于中大型信息系统了。常用的组件都已经集成在软件开发架构里了，比如工作流引擎，权限管理模块，微服务接口的发布，鉴权及限流，消息模块的集成，公用组件类的集成（且可以后续扩展），前端界面要求不高的直接用内置的代码生成器工具直接生成。要求较高的则有专业前端来开发和调整。各个业务模块可以在架构设计最初做好切割，方便分布式发布，且各个模块分布式发布都可以自成一体，配置对应独立的业务数据库和LB；

(2) 优劣势结论

从如上分析可以看出，各种架构和模式适用的场景不同，针对小微系统，可以随意选择如上A和B，针对中型系统，可以选择C，针对大型系统，只能选择D了。

3，基于微服务的脚手架

(1) 架构图

这里架构图只给出了一组nginx，主要是示例gateway的LB，实际上，微服务端（即每个Gateway都可以切割成一组独立的业务模块）是可以按业务领域切割部署，每个领域单独部署一组nginx服务器；其对应的数据库也是可以按组部署单独的多节点以及读写分离；

(2) 框架功能说明

(3) 开发简介

① 所有的业务逻辑均到指定的业务逻辑层直接编写，测试后就可以作为微服务发布出来；

② 需要用到如上框架说明的功能的，无需从0开发，直接使用现有的集成好的接口即可，门槛低，上手快；如工作流，微信，支付宝收款，API微服务鉴权，文件系统等；

③ 前端页面早期可以安排专业前端设计好几个常用类别，后续其它类似界面后端开发人员只要能够简单看懂前端代码即可稍作修改，直接使用；简单的前端页面可以利用框架自带的拖拉拽设计器设计出来，然后复制代码后根据需要调整即可。

④ 所有的组件均集成好拆箱即用；

⑤ 支持服务器群组和负载均衡；

it系统架构的发展所经历的阶段 全球it系统建设架构