架构设计

来自小米的一张讲座图，说的不错，说的企业架构设计建模方法： 来源： CSDN 作者： jackyrongvip 链接： https://blog.csdn.net/jackyrongvip/article/details/104011367

由于软件系统的复杂性，一般人很难非常清楚的将整个系统理的很清楚，所以才会出现架构视图的概念，而架构视图出现的一个主要动力或者原则就是：分而治之。 分而治之有两种类型 1. 按问题深度分而治之，即先不把问题想的那么深入，那么仔细，要浅尝辄止。例如定义各个模块之间的接口就属于这种，先不考虑如何实现接口，只是定义模块之间进行通信时的契约。 2. 按问题广度分而治之，即先不研究整个问题，而是研究问题的一部分，分割问题，各个击破。例如采取 MVC 架构进行开发时，每一层都属于一个比较深入的部分。 软件架构应该采取哪种方式？ 所谓架构设计，是关于如何构建软件的一些最重要的设计决策，这些决策往往是围绕着系统分为哪些部分，各部分之间如何交互进行展开的。 所谓详细设计，则是针对每个部分的内部进行设计。 所以可以说对于架构设计，应该采取按照问题深度分而治之，关注的是系统的整体设计；而详细设计时应该采取按照问题广度分而治之，关注的是每个模块如何实现。 软件架构是团队开发的基础 一方面，架构从大局着手，就技术方面的重大问题作出决策，构造一个具有一定抽象层次的解决方案，而不是将所有细节全部展开，从而有效的控制了‘技术复杂性’。 另一方面，因为架构中包含了关于各元素应该如何彼此交互的信息，所以可以把不同的模块分配给不同的小组分头开发，架构在中间扮演‘桥梁’和‘合作契约’的作用。 架构应该设计到什么程度？ 1.

本文节录温昱先生《软件架构设计》第8章 软件架构要做到什么程度，并将自己的理解在节录后做出描述。希望节录部分能给大家带来收获和感悟。并对我的理解部分提出建议和想法。 OK,让我们开始吧.解决软件架构到底要设计到什么程度? * 首先，对软件架构的设计程度问题展开探讨，得出基本结论。从对“分而治之”的讨论入手，说明软件架构是团队开发的基础，从而，软件架构必须设计到“能为开发人员提供足够的指导和限制”的程度； * 之后，从问题入手，认识高来高去式架构设计的“症状”。主要分析实际工作中常见的架构设计不足的几种表现，找到要解决的问题； * 然后，说明如何解决架构设计高来高去、指导不足的问题； * 最后，结合案例，说明如何一步步地将架构设计落实到实处。 ------------------------------------------------------------------------------------- 8.1 软件架构要设计到什么程度 软件架构必须设计到“能为开发人员提供足够的指导和限制”的程度。 8.1.1 分而治之的两种方式 为什么要分而治之?简单说，就是问题太复杂了，超出了人们能够“一蹴而就”的范围。 面对一个复杂的问题，我们如何进行分而治之呢？策略有二： 一、先不把问题研究得那么深，那么细，浅尝辄止，见好就收。这种分而治之的方式称为“按问题深度分而治之”。 二

小伙伴们，新年好！ 感谢大家对「 IT老兵哥 」原创文章的支持顶赞，❤️❤️❤️！把有价值的知识或经验分享给更多人，在分享中提升个人价值，这是我写作、分享的初衷和动力，在新的一年里我会更加努力，也希望能够继续获得各位小伙伴的支持！坚持原创不易，如果文章有价值，千万要记得手动点个「 👍 」哦！ 祝大家新年在家庭、事业和生活上都有新的进步！关注「 IT老兵哥 」，赋能程序人生，我们一起加油干！⛽️⛽️⛽️ 年前我们一起聊了 程序员为什么要懂架构 、 架构是什么 和 架构都有哪些类型 这三个话题，今天我们来看看架构师是怎样开展工作的，他/她需要对接上下游哪些角色，以什么作为工作输入，最终要对外输出什么产物。这些内容既有助于我们跟架构岗同事更好的协作，也可以作为是否往架构转型的参考，接下来我们一起揭开架构师的神秘面纱吧！ 1. 架构设计的输入是什么？ 软件系统最终要构建成什么样，这是由项目干系人的各种要求决定的。通常，我们将这些要求归集在产品需求文档之中，这份产品需求就是架构设计的输入。我们可以将这些需求划分为： 功能需求：完成某项业务需要的功能操作，例如：共享单车客户端软件需要支持单车定位、扫码解锁等。 质量需求：每项功能操作要达到什么样的质量要求，例如：易用性、可靠性、安全性、性能等等。 商业需求：软件系统需要以什么样的成本、迭代速度推向市场，如何提升产品的市场竞争力等等。 2.

前言 什么是微服务？ 微服务（Microservice Architecture）是近几年流行的一种架构思想，关于它的概念很难一言以蔽之。简而言之，微服务架构风格是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。 这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。 这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储技术。 正文 微服务是当前非常流行的技术框架，通过服务的小型化、原子化以及分布式架构的弹性伸缩和高可用性，可以实现业务之间的松耦合、业务的灵活调整组合以及系统的高可用性。为业务创新和业务持续提供了一个良好的基础平台。本文分享在这种技术架构下的数据架构的设计思想以及设计要点，本文包括下面若干内容。 微服务技术框架中的多层数据架构设计 数据架构设计中的要点 要点1：数据易用性 要点2：主、副数据及数据解耦 要点3：分库分表 要点4：多源数据适配 要点5：多源数据缓存 要点6：数据集市 为了容易理解，本文用一个简化的销售模型来阐述，如下图。图1显示了客户、卖家、商品、定价、订单的关系（这里省略支付、物流等其他元素）。 图1 销售模型 在这个销售模型中，卖家提供商品、制定价格，客户选择产品购买、形成销售订单。根据微服务的理念设计，可以划分为客户服务、卖家服务

QQ 1285575001 Wechat M010527 技术交流 QQ群599020441 纪年科技aming 1.设计app架构 1.梳理app业务流程 2.整理业务流程可能遇到的问题 3.根据问题，探讨可执行的解决方案 4. app后台 初步架构 ：3中所有技术进行有机融合 api编写： 1.api的作用（功能） 2.api需要输入的参数 3.api返回的数据 2.服务器选择 1.传统的IDC 在传统的IDC，要加cpu或内存，流程如下: 　　1.和客户经理商商谈所需硬件的价格 　　2.汇款过去，等IDC的财务确认 　　3.确认后，等待IDC安排工作人员升级硬件 　　这个流程走一次，最少也要1至2天。延迟了1至2天升级硬件，怎么保证可以快速应付爆发的业务 2.云服务器 升级硬件: 1.在用户后台选择需要的硬件配置 　　2.通过网络支付 　　3.重启服务器，升级就完成了。如果只是升级带宽，甚至不用重启。 　　整个过程合起来不用5分钟，简单，快捷，方便。 　　而且，现在的云服务器提供商，除了服务器外，还提供下面的服务： 　　负载均衡 　　云数据库 　　云内存存储 　　这些服务在app上线初期，在一台服务器上自己搭建就行了， 　　但随着app的发展，这些服务都需要部署在不同的服务器。 　　 　　规模的增大，也要面对高可用，高并发，监控报警等问题。 　　这些问题如果都要后端人员处理

弹性可伸缩微服务架构设计中的流控话题探讨 先简单谈可伸缩弹性服务架构 流控的意义 流控原理（或称方法论） 案例及demo 先简单谈可伸缩弹性服务架构 先简单谈弹性可伸缩服务架构,具体的架构设计后面会有文章详细介绍。 何为弹性？何为可伸缩？其实这是架构设计中除了考虑高可用，高稳定性，高性能，易扩展因素外更进一步的思考。 弹性，顾名思义，面对剧烈冲击的时候仍能应保持正常功能和服务。剧烈冲击一般可以理解为突增流量。 可伸缩，一般指服务节点和整体服务器资源的可动态调度和部署。 具体方案这里不详细展开，这里着重谈一下在弹性架构设计中经常用到的流程手段和原理。 流控的意义 流量一般都会经过反向代理层，应用服务层，数据层，而者每一层之间都因该有流量控制组件的身影，每一层流控的目的和意义都不一样，但总体都是为了保证整体应用的高可用性和高稳定性，各个层的流控作用如下： 反向代理层 过滤恶意流量，主要是对恶意攻击流量和爬虫进行甄别 灰度测试的流量分发 对后端服务层的QPS过载保护 2. 服务层 可以通过微服务框架对服务和接口进行治理包括，服务降级，限流等 对第三方接口进行QPS过载保护 数据层 包括通过限流组件防止流量雪崩式的压向数据库，避免数据库的服务端因某个应用的tps过高而引发资源问题 流控原理（或称方法论） 漏桶原理 （leaky bucket） 简单的说就是桶是有容量（capacity

七大设计原则 一.开闭原则 开闭原则（Open-Closed Principle, OCP）是指一个软件实体（如类、模块和函数）应该对扩展开放，对修改关闭。所谓的开闭，也正是对扩展和修改两个行为的一个原则。它强调的是用抽象构建框架，用实现扩展细节，可以提高软件系统的可复用性及可维护性。开闭原则是面向对象设计中最基础的设计原则，它指导我们如何建立稳定、灵活的系统。例如版本更新，我们尽可能不修改源代码，但是可以增加新功能。 二.依赖倒置原则 依赖倒置原则（Dependence Inversion Principle， DIP）是指设计代码结构时，高层模块不应该依赖底层模块，二者都应该依赖其抽象。抽象不应该依赖细节，细节应该依赖抽象。通过依赖倒置，可以减少类与类之间的耦合性，提高系统的稳定性，提高代码的可读性和可维护性，并且能够降低修改程序所造成的风险。 三.单一职责原则 单一职责原则（Simple Responsibility Pinciple, SRP）是指不要存在多于一个导致类变更的原因。假设我们有一个类负责两个职责，一旦发生需求变更，修改其中一个职责的逻辑代码，有可能导致另一个职责的功能发生故障。这样一来，这个类就存在两个导致类变更的原因。如何解决这个问题呢？将两个职责用两个类来实现，进行解耦。后期需求变更维护互不影响。这样的设计可以降低类的复杂度，提高类的可读性

难点： 高并发—超出最大服务数【分布式、Redis缓存、 集群、分布式锁】 单用户多次操作—抢购狂点，如何达到仅处理一次【消息的幂等性】 保证抢购的顺序【消息队列排队】 业务架构：描述系统可以做什么的架构 微信登录、用户名密码登录 抢购 微信支付、支付宝支付 应用架构：描述系统业务应用分类的架构 用户业务 商品业务 订单业务 支付业务 技术架构：描述系统技术实现的架构 前后端分离 Dobbo协议 DobboX框架 Nginx集群—>API Consumer—->对外提供接口。api service Zookeeper Registration —注册中心 Provider层：包括DAO层（springboot） 数据仓库：MySQL，MQ，Redis 部署架构：描述系统如何进行部署的架构 Docker：一台服务器可以模拟出很多模拟服务器，模拟集群环境 优点：比虚拟机效率高，可以直接部署到真正的集群系统 消费者（用户消费者、商品、订单、支付消费者） 生产者（用户、商品、订单、支付生产者） 基础服务，每个单独部署一台服务器 Ngnix-负载均衡、 MySql、 Redis-缓存、 Zookeeper-、分布式服务架构-文件系统+监听通知机制 Dubbo、分布式服务框架、高性能和透明化的RPC远程服务调用方案、SOA服务治理方案 ActiveMQ、消息中间件、kafka、rabitmq

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 简单的说，微服务是架构设计方式，分布式是系统部署方式，两者概念不同 微服务是啥？ 这里不引用书本上的复杂概论了，简单来说微服务就是很小的服务，小到一个服务只对应一个单一的功能，只做一件事。这个服务可以单独部署运行，服务之间可以通过RPC来相互交互，每个微服务都是由独立的小团队开发，测试，部署，上线，负责它的整个生命周期。 微服务架构又是啥？ 在做架构设计的时候，先做逻辑架构，再做物理架构，当你拿到需求后，估算过最大用户量和并发量后，计算单个应用服务器能否满足需求，如果用户量只有几百人的小应用，单体应用就能搞定，即所有应用部署在一个应用服务器里，如果是很大用户量，且某些功能会被频繁访问，或者某些功能计算量很大，建议将应用拆解为多个子系统，各自负责各自功能，这就是微服务架构。 那么分布式又是啥？ 分布式服务顾名思义服务是分散部署在不同的机器上的，一个服务可能负责几个功能，是一种面向SOA架构的，服务之间也是通过rpc来交互或者是webservice来交互的。逻辑架构设计完后就该做物理架构设计，系统应用部署在超过一台服务器或虚拟机上，且各分开部署的部分彼此通过各种通讯协议交互信息，就可算作分布式部署，生产环境下的微服务肯定是分布式部署的，分布式部署的应用不一定是微服务架构的，比如集群部署