比如希赛推的ADMEMS架构体系，分为以下几种视图：
1. 数据架构：描述数据的存储结构、格式等方面。
2. 物理架构：描述机器的物理部署、网络拓扑方面。
3. 运行架构：描述运行期线程、进程间的交互工作机制。
4. 逻辑架构：指如何将代码分成不同模块、组件，以及之间的职责分配、交互行为。
5. 开发架构：主要指开发工具的选择，程序单元的划分，开发管理规范流程等方面。例如分为哪些工程、项目，源代码管理，自动化编译构建、测试、部署等。
目前国际上运用比较广泛的是TOGAF架构体系，他把架构分为业务架构、数据架构、应用架构、技术架构等几个方面。
想详细的了解这些架构视图，可以参考这些架构体系相关的书、资料。
另外有很多人无缘无故的抨击架构概念，不知道是出于调侃还是无知。埃及的金字塔、神庙的建设，不是几个平常的泥瓦匠聚在一起就能够造出来的。像SAP、Oracle ERP，国内的金蝶等大规模的系统，以及空间站、火箭的控制系统等，没有系统性的架构方法、规范、流程，结果只能是悲剧。
当规模、复杂度没有达到一定程度，比如在一些小的团队、产品中，架构过程可能融入到老板、经理、组长、资历较深的一些开发者中，融入在大家的日常工作中，以至于感觉不到架构的存在。就算遇到一些问题，因规模不大、复杂度不高，也比较容易调整。当这些前提条件发生变化时，架构的作用和必要性就逐步的体现出来。
总的来说，一说到架构，如果你懂软件，那么你会了解为一个软件系统，这个软件设计的组成结构，如哪些是基础支持组件，哪些是完成A业务，哪些完成B业务。。。但说道企业架构的时候，就会问，该企业架构的几个架构如业务架构、数据架构、业务架构、技术架构，以及他们如何链接在一起。我倒觉得，一个企业确实需要这样的架构，但不要神话它，最主要的是业务如何最终体现到软件中和流程中。而采取分离式设计时，最容易的错误就是各自为政，集成困难。那么以数据为中心的架构设计，会自然提供集成的基础。我提到过，企业最重要的资产是数据，甚至不是信息，是数据。企业的业务流程会变，IT系统会变，所需要的信息与知识会变，唯有数据能够积淀下来。这有点象自然演进，考古那种，啥都会消失，唐朝可以无比先进，但都会变，我们唯有找到反映当时情况的数据，才可以把握当思的面貌。
昨天科技圈最火的新闻应该是“AWS中国区光缆被挖，导致三星、小米等众多企业服务不可用”。
又是光缆被挖，咦！？为什么是又，让我们来一起回到过去：
我这里只是列出来了几家大公司所涉及到的光缆被挖事故，其余还包括什么广电光缆被挖，社保局光缆被挖就不列了，感兴趣的自己去百度。
好，我们发现“公司再大，也怕施工队”，那么这种事故能怪施工队吗？个人觉得不能把责任都推给施工队，当然我们这里不讨论这些，我们做为大公司，我们以后怎么预防这种现象呢？
这个我们可以来看下支付宝的解决办法，毕竟它老人家在2015年就经历过这种惨况了。
这种解决办法就是“三地五中心”，这是一种机房架构，即在三座城市部署五个机房，一旦其中一个或两个机房发生故障，依靠技术可以将故障城市的流量全部切换到运行正常的机房。
那么在“三地五中心”之前还存在很多其他架构，我们一一来看一下他们的特点。
最初，我们把应用(一个非常简单的只读应用，比如一个显示Hello World的网页，不考虑数据存储)只放在一个机器上，那么当这个服务器down机了，我们的应用便不可用了。
所以，我们考虑把我们的应用放在多个机器上，在公司单独开辟一个机房来放置这些机器，这样单独某一个台机器down机了并不影响我们的应用。
但是，如果你们公司某一天停电了呢？这个时候我们就考虑在这座城市的另外一个地方在放置一个机房，这是应用就被部署在了同城的两个机房（这个叫 同城双活 ）
但是，如果你们城市某一天经历了海啸、台风、地震等自然灾害，两个机房都不能使用了，这个时候我们就会考虑在另外一个城市再搭建一个机房来部署我们的应用，这样我们应用的可用性就更高了（这个叫 异地多活 ）。
好，到此为止不管出现什么样的状况，我们的应用基本上都可用（除非地球毁灭...）
那么我们上面考虑的应用是一个非常简单的只读应用，所以各个地方的应用是可以同时对外提供服务的，那么如果我们的应用涉及到数据存储，这个时候各个地方的应用就不能同时对外提供 写入数据 的服务了，因为很有可能会出现数据冲突，那么我们暂且规定只有公司内部机房里的服务器（后文我们叫主机房）可以提供写数据服务，而同城的另外一个机房以及异地的另外一个机房只能从主机房同步数据，这样这两个地方的机房的功能就叫 灾备 ，因为数据会同步，所以就算主机房停电了，另外两个机房还是可以临时来对外提供服务的。所以现在的架构可以如下：
这个就叫 两地三中心 。
那么两地三中心这种架构是目前很多银行或大型企业正在使用的一种架构，因为国家针对银行的灾备能力做过要求，资产超过多少多少的一定要做两地三中心架构，以保证银行系统的稳定。
那么这种架构有没有它的缺点呢？我们来考虑一下它的可用性高不高？可用性的意思就是这个架构处理用户请求时够不够快？
我们发现这种架构，中心之间是需要数据备份的，那么对于数据备份只有两种方式，要么异步，要么同步。
好，我们介绍了一下两地三中心，总结一下它的缺点：
那么为了解决这个问题，就出现了 三地五中心 ，虽然名字和两地三中心类似，但提供的功能完全不同。
三地五中心是指三个城市，5个中心，三地五中心基于的概念是单元化，还得花很大篇幅来讲，下一篇继续吧。
数据流图，程序结构图和系统结构图的区别和联系如下：
1、数据流图（Data Flow Diagram），简称DFD，它从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。它是描绘信息流和数据从输入移动到输出的过程中所经受的变换。
2、系统流程图（System Flowchart）是描绘系统物理模型的传统工具。它的基本思想是用图形符号以黑盒子形式描绘系统里面的每个部件(程序、文件、数据库、表格、人工过程等），表达信息在各个部件之间流动的情况，而不是表示对信息进行加工处理的控制过程。
3、数据流程图：反应数据走向 ，它不考虑时序关系，是业务分析用的，用作详细设计。图中的有向线段表示了数据流。
4、程序流程图：程序逻辑 描述程序中控制流的情况,即程序中处理的执行顺序和执行序列所依赖的条件,图中的有向线段表示的是控制流,从一个处理走到下一个处理。
5、系统结构图：反映的是系统中模块的调用关系和层次关系,谁调用谁,有一个先后次序(时序)关系。图中的有向线段表示调用时程序的控制从调用模块移到被调用模块,并隐含了当调用结束时控制将交回给调用模块。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）