记录－交流－Web开发知识分享
大家好，我是飞哥！最近我简单研究了一下低延迟网络架构，今天和大家分享分享。
谈到优秀的低延时网络架构，大家首先可能想到的是各家互联网大厂，比如腾讯阿里字节，总会觉得大厂做的肯定最好。但其实在在一般的互联网应用中，用户虽然也讨厌卡顿，但整体上来对延迟其实并不算太敏感，只要按钮点下后一秒之内能响应，用户就基本感觉不出来。甚至是两三秒才响应用户也都还能接受。
所以在今天的互联网公司中，虽然也关注服务访问延迟，但其实优化并没有往特别极致了去做。…
工作 20 多年了，这 20 来年看到了很多公司系统架构，也看到了很多问题，在跟这些公司进行交流和讨论的时候，包括进行实施和方案比较的时候，都有很多各种方案的比较和妥协，因为相关的经历越来越多，所以，逐渐形成了自己的逻辑和方法论。今天，想写下这篇文章，把我的这些个人的经验和想法总结下来，希望能够让更多的人可以参考和借鉴，并能够做出更好的架构来。另外，我的这些思维方式和原则都针对于现有市面上众多不合理的架构和方案，所以，也算是一种“纠正”……（注意，这篇文章所说的这些架构上的原则，一般适用于相对比较复杂的业务，如果只是一些简单和访问量不大的应用，那么你可能会得出相反的结论）…
原文：https://herbertograca.com/2017/07/03/the-software-architecture-chronicles/
译者：最早看到的是作者的这篇文章(译文)，其中的那副信息图可谓集软件架构之大成。后来发现这是作者学习和思考软件架构发展史的系列文章之一。“以史为鉴，可以知兴替”，阅读历史就是学习的过程。翻译也不例外，我也是通过阅读和翻译来学习软件开发的历史，联系作者获得授权之后便有了这一系列译文。
这是软件架构系列的第一篇文章。我将我对软件架构的学习过程和思考以及我是如何运用这些知识的写成这一系列文章。
我把这一系列文章称为“软件架构编年史”，并不是因为我觉得自己的文笔不错，而是想用一种有趣的方式旧调重弹！😀
单个应用程序，我们称之为Monolith，是通过单个部署单元提供的应用程序。示例可以是作为单个WAR提供的应用程序，也可以是具有单个入口点的Node应用程序。
让我们举个例子：一个经典的在线商店。我们的业务范围包括订单，项目，客户，运输和付款。提供的与服务交互的方式有：REST api和Web前端。
构建Monolith，所有这些东西都将在同一个工件中进行管理。我没有编写“相同的进程”，因为对于我们的工件的多个实例将运行以处理更高负载的情况，这不是真的。
一：emqtt的架构设计为：
Topic tree每台机器有副本，down机不影响数据
连接、订阅是单节点，一台down机客户端必须重连其他节点，并重新订阅相关主题。
二：官方推荐部署架构为：
今天是2019年2月12号，也就是大年初八，我接到了高中同学刘有码面试失利的消息。
他面试的时候，身份是某知名公司的小码农一枚，却因为不懂自己生产上Redis是如何部署的，导致面试失败！
人间惨剧，莫过于此。
接到他面试失利的消息，我差点发出猪一样的笑声，显然是平时太少关注孤独烟这个公众号！
我提笔6次，放笔6次，差点因为过于兴奋而没法编下去。最后还是硬着头皮写下了本文!…
…摘要： 技术传播的价值，不仅仅体现在通过商业化产品和开源项目来缩短我们构建应用的路径，加速业务的上线速率，也体现在优秀工程师在工作效率提升、产品性能优化和用户体验改善等经验方面的分享，以提高我们的专业能力。
阿里妹导读：技术传播的价值，不仅仅体现在通过商业化产品和开源项目来缩短我们构建应用的路径，加速业务的上线速率，也体现在优秀工程师在工作效率提升、产品性能优化和用户体验改善等经验方面的分享，以提高我们的专业能力。
接下来，阿里巴巴技术专家三画，将分享自己和团队在画好架构图方面的理念和经验，希望对你有所帮助。
当我们想用一张或几张图来描述我们的系统时，是不是经常遇到以下情况：
- 对着画布无从下手、删了又来？
- 如何用一张图描述我的系统，并且让产品、运营、开发都能看明白？
- 画了一半的图还不清楚受众是谁？
- 画出来的图到底是产品图功能图还是技术图又或是大杂烩？
- 图上的框框有点少是不是要找点儿框框加进来？
- 布局怎么画都不满意……
如果有同样的困惑，本文将介绍一种画图的方法论，来让架构图更清晰。
先厘清一些基础概念
1、什么是架构？
架构就是对系统中的实体以及实体之间的关系所进行的抽象描述，是一系列的决策。
架构是结构和愿景。
系统架构是概念的体现，是对物/信息的功能与形式元素之间的对应情况所做的分配，是对元素之间的关系以及元素同周边环境之间的关系所做的定义。
做好架构是个复杂的任务，也是个很大的话题，本篇就不做深入了。有了架构之后，就需要让干系人理解、遵循相关决策。
2、什么是架构图？
系统架构图是为了抽象地表示软件系统的整体轮廓和各个组件之间的相互关系和约束边界，以及软件系统的物理部署和软件系统的演进方向的整体视图。
3、架构图的作用
一图胜千言。要让干系人理解、遵循架构决策，就需要把架构信息传递出去。架构图就是一个很好的载体。那么，画架构图是为了：
- 解决沟通障碍
- 达成共识
- 减少歧义
4、架构图分类
搜集了很多资料，分类有很多，有一种比较流行的是4+1视图，分别为场景视图、逻辑视图、物理视图、处理流程视图和开发视图。
场景视图
场景视图用于描述系统的参与者与功能用例间的关系，反映系统的最终需求和交互设计，通常由用例图表示。
逻辑视图
逻辑视图用于描述系统软件功能拆解后的组件关系，组件约束和边界，反映系统整体组成与系统如何构建的过程，通常由UML的组件图和类图来表示。
物理视图
物理视图用于描述系统软件到物理硬件的映射关系，反映出系统的组件是如何部署到一组可计算机器节点上，用于指导软件系统的部署实施过程。
处理流程视图
处理流程视图用于描述系统软件组件之间的通信时序，数据的输入输出，反映系统的功能流程与数据流程,通常由时序图和流程图表示。
开发视图
开发视图用于描述系统的模块划分和组成，以及细化到内部包的组成设计，服务于开发人员，反映系统开发实施过程。
以上 5
企业规模的软件系统该如何设计呢？在开始写代码之前，我们需要选择一个合适的架构，这个架构将决定软件实施过程中的功能属性和质量属性。因此，了解软件设计中的不同架构模式对我们的软件设计会有较大的帮助。
什么是架构模式？根据维基百科：架构模式是针对特定软件架构场景常见问题的通用、可重用解决方案。架构模式类似于软件设计模式，但范围更广。本文将简要解释10种常见架构模式及其用法、优缺点。
近期评论