一文搞懂业务架构、技术架构、数据架构、运维架构、物理架构理清差别视角的
<blockquote class="multiquote-1" style="border: none; display: block; font-size: 0.9em; overflow: auto; overflow-scrolling: touch; border-left: 3px solid rgba(0, 0, 0, 0.4); color: #6a737d; padding-top: 10px; padding-bottom: 10px; padding-left: 20px; padding-right: 10px; margin-bottom: 20px; margin-top: 20px; border-left-color: rgb(239, 112, 96); background: #fff9f9;"> 在学习架构时，我以为首先要理清晰架构的视角，由于你所认知的架构和别人所说的架构大概是两码事。对于差别职位的视角是不一样的，比如开发而言他更多的看到的是开发架构；对售前人员，他大概更多的看到的是业务架构；对于运维人员，他看到的大概是运维架构；而对于技术支持和摆设人员，他更多的看到的网络和物理架构。架构的视角
在笔者的知识体系中，实际大将架构分为业务架构、应用架构、云基础架构这几大类，业务架构重要着眼于控制业务的复杂性，基础架构着眼于解决分布式系统中存在的一系列题目。无论何种架构，都希望能实现系统的可变的同时保障业务的高可用。
[*] 很多时候架构的视角/分类没有明显的界限，通常是交织的；
[*] 故意思的是，软件架构及其视角往往和它地点的部门组织架构有着直接关系。@pdai
业务架构
焦点是解决业务带来的系统复杂性，了解客户/业务方的痛点，项目界说，现有环境；梳理高阶需求和非功能性需求，举行题目域划分与领域建模等工作；沟通，方案发起，多次迭代，交付总体架构。
https://img-blog.csdnimg.cn/img_convert/8c0464dd4e8d5774514adb9665c5bbaa.png 看看京东业务架构（网上分享图）：
https://img-blog.csdnimg.cn/img_convert/e4c842c28a4fc3bb369e6f4d3f5b392b.png 应用/技术架构
根据业务场景的必要，设计应用的层次布局，制定应用规范、界说接口和数据交互协议等。并只管将应用的复杂度控制在一个可以继承的水平，从而在快速的支撑业务发展的同时，在保证系统的可用性和可维护性的同时，确保应用满足非功能属性要求（性能、安全、稳定性等）。技术架构重要考虑系统的非功能性特性，对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。
<blockquote class="multiquote-1" style="border: none; display: block; font-size: 0.9em; overflow: auto; overflow-scrolling: touch; border-left: 3px solid rgba(0, 0, 0, 0.4); color: #6a737d; padding-top: 10px; padding-bottom: 10px; padding-left: 20px; padding-right: 10px; margin-bottom: 20px; margin-top: 20px; border-left-color: rgb(239, 112, 96); background: #fff9f9;"> 不限于如下视角，重要表现应用开发中的软件架构视角...
视角：功能视角
<blockquote class="multiquote-1" style="border: none; display: block; font-size: 0.9em; overflow: auto; overflow-scrolling: touch; border-left: 3px solid rgba(0, 0, 0, 0.4); color: #6a737d; padding-top: 10px; padding-bottom: 10px; padding-left: 20px; padding-right: 10px; margin-bottom: 20px; margin-top: 20px; border-left-color: rgb(239, 112, 96); background: #fff9f9;"> 功能视角和业务视角有重合的地方，重要针对开发而言的服务功能；
视角：技术视角-总体
技术框架（technological Framework）是整个或部分技术系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法;另一种界说以为，技术框架是可被技术开发者定制的应用骨架。前者是从应用方面而后者是从目的方面给出的界说。
从技术层面形貌，重要是分层模子，例如持久层、数据层、逻辑层、应用层、表现层等，然后每层使用什么技术框架，例如Spring、hibernate、ioc、MVC、成熟的类库、中间件、WebService等，分别说明，要求这些技术能够将整个系统的重要实现概括。
https://img-blog.csdnimg.cn/img_convert/84b16223153fa734ebaac949e68a226e.png 视角：技术视角-数据架构
专注于构建数据中台，同一数据界说规范，标准化数据表达，形成有效易维护的数据资产。打造同一的大数据处理平台，包罗数据可视化运营平台、数据共享平台、数据权限管理平台等。
视角：技术视角-基础架构
PAAS，IAAS...
https://img-blog.csdnimg.cn/img_convert/3e324b110179dcf061416cb3c574ed5d.png 视角：技术视角-运维架构
负责运维系统的规划、选型、摆设上线，创建规范化的运维体系。
https://img-blog.csdnimg.cn/img_convert/ecf41c5b29d5e5bca777ec485e2bc7f0.png 物理架构
物理架构关注软件元件是怎样放到硬件上的，专注于基础办法，某种软硬件体系，甚至云平台，包罗机房搭建、网络拓扑布局，网络分流器、署理服务器、Web 服务器、应用服务器、报表服务器、整合服务器、存储服务器和主机等。
以一个银行系统为例
下面为业务性能及网络性能监控的物理摆设架构图，分网络接入层和汇聚层两个层次对网络流量报文举行捕捉和深入分析。
https://img-blog.csdnimg.cn/img_convert/146b23596c68ed5443d5ebad56b55f2d.png 物理摆设架构设计说明：
[*] （1）通过4台TAP设备获取青山湖和艾溪湖两个数据中心、五个机房相关应用服务器接入交换机的镜像流量，并举行规则过滤；
[*] （2）通过1台高性能汇聚TAP来获取艾溪湖数据中心二层汇聚交换机和焦点交换机的镜像流量，并举行规则过滤；
[*] （3）艾溪湖主数据中心各机房接入层TAP设备的流量共享给汇聚TAP设备；
[*] （4）BPC系统的5台BPC服务器在两个数据中心的每个机房举行分布式摆设、解码和分析，并集中展示；
[*] （5）NPM系统在艾溪湖数据中心摆设一台管理端服务器，并在每个数据中心各摆设一台NPM探针服务器，通太过布式摆设、捕捉数据，集中监控展示的方式，监控两个数据中心的各业务系统的网络性能；
[*] （6）通过双数据中心、多机房分布式摆设的方式，端到端的监控业务在各个环节的流转情况，实时监控，快速定位。
下面为运维大数据平台的物理摆设拓扑图，分为三个集群，Hadoop集群、ES日志集群和Kalfka消息集群。
https://img-blog.csdnimg.cn/img_convert/da0d26f1c1184de08ef6f1104668e1ce.png 物理摆设架构设计说明：
[*] 设置多台服务器做Hadoop集群，满足差别应用和系统日志的单系统与跨系统生意业务日志统计与分析，满足数千个基础监控分区的基础性能分析与运行性能指标预测等，以及指性能标入库与历史日志数据入库的存储必要。
[*] 设置多台服务器做ES集群，承载实时同一日志查询与分析平台的任务，满足数天至一个月差别需求的日志查询和分析需求，历史日志查询必要从HDFS中将数据导入至ES中，举行二次查询。
[*] 设置多台服务器做Kafka集群用于实时的指标型与日志型数据流的采集，满足实时监控的需求。
DDD到各种架构
领域驱动设计的战略焦点即是将题目域与应用架构相剥离，将业务语义显现化，把原先晦涩难懂的业务算法逻辑，通过领域对象（Domain Object），同一语言（Ubiquitous Language）转化为领域概念清晰的显性化表达出来。
[*] 同一语言，软件的开发人员/使用人员都使用同一套语言，即对某个概念，名词的认知是同一的，创建清晰的业务模子，形成同一的业务语义。将模子作为语言的支柱。确保团队在内部的全部交流中，代码中，绘图，写东西，特别是发言的时候都要使用这种语言。例如账号，转账，透支策略，这些都黑白常重要的领域概念，如果这些命名都和我们日常讨论以及 PRD 中的形貌保持一致，将会极大提拔代码的可读性，减少认知本钱。。比如不再会有人在聚会会议中对“工单”、“考核单”、“表单”而反复确认含义了，DDD 的模子创建不会被 DB 所绑架。
[*] 面向领域，业务语义显性化，以领域去思索题目，而不是模块。将隐式的业务逻辑从一推 if-else 内里抽取出来，用通用语言去命名、去写代码、去扩展，让其酿成显示概念；很多重要的业务概念，按照事件脚本的写法，其含义完全淹没在代码逻辑中没有突显出来。
[*] 职责划分，根据实际业务公道划分模子，模子之间依赖布局和界限更加清晰，避免了混乱的依赖关系，进而增长可读性、可维护性；单一职责，模子只关注自身的本职工作，避免“越权”而导致混乱的调用关系。通过建模，更好的表达实际世界中的复杂业务，随着时间的发展，不停增长系统对实际业务的沉淀，也将更好的通过清晰的代码形貌业务逻辑，模子的内聚增长了系统的高度模块化，提拔代码的可重用性，对比传统三层模式中，很有大概大量重复的功能散落在各个 Service 内部。
https://img-blog.csdnimg.cn/img_convert/06c8f0e8ae7db2d77dffdc1e5513d937.png 参考文章
[*] https://blog.csdn.net/wxyyxc1992/article/details/100129049
[*] https://baijiahao.baidu.com/s?id=1608647829654152773&wfr=spider&for=pc
[*] https://blog.csdn.net/zhangbijun1230/article/details/81979535
[*] https://blog.csdn.net/ITLearnHall/article/details/82985480
[*] http://www.talkwithtrend.com/Article/243093
[*] https://segmentfault.com/a/1190000020220143 著作权归@pdai全部 原文链接：https://pdai.tech/md/arch/arch-x-view.html
本文由 mdnice 多平台发布
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]