记录－交流－Web开发知识分享
单个应用程序，我们称之为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种常见架构模式及其用法、优缺点。
…这里所说的三架马车是指微服务、消息队列和定时任务。如下图所示，这里是一个三驾马车共同驱动的一个立体的互联网项目的架构。不管项目是大是小，这个架构模板的形态一旦定型了之后就不太会变，区别只是我们有更多的服务有更复杂的调用，更复杂的消息流转，更多的Job，整个架构整体是可扩展的，而且不会变形，这个架构可以在很长的一段时间内无需有大的调整。…
微服务是一种架构风格，一个大型的复杂软件由一个或多个微服务组成。系统中每个微服务都可以被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成任务。在所有情况下，每个任务代表这一个小的业务能力。
微服务的核心思想是：一个完整的应用由多个小的、相互独立的微服务组成，这些微服务运行在自己的进程中，开发和发布都没有依赖。不同微服务通过一些轻量级交互机制来通信，例如RPC、HTTP等，服务可独立拓展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立团队维护。简单的来说，一个系统的不同模块转变成不同的服务！而且服务可以使用不同的技术加以实现！…
近期评论