架构设计

本 系列 前序文章索引： 程序员 为什么必须要懂架构？ 架构到底是什么，你知道吗？ 架构都有哪些，我该怎么选？ 架构师都干什么，你知道吗？ 练就哪些技能才胜任架构师？ 架构师， 在开展工作的过程中需要对接老板、产品、项目、开发、测试、安全和运营等各种岗位角色，他们都是架构需要关注和服务的内部客户，他们的痛点就是架构工作的驱动因素。架构师就是要用专业技能“搞定”这些角色的需求，输出大家都能接受的解决方案，大家好才是真正的好。为了达成此目的，我们必须知道不同岗位的关注点。 老板产品 老板的主要职责就是定方向、找人、找钱，他对架构设计的要求就是在给定的预算、时间范围内研发出软件系统，推动公司的战略或战术得以实现，也就是说架构方案不能过于理想，不能超出预算和截止时间。自从苹果公司的乔布斯封神之后，现在的互联网公司都崇尚老板担当首席产品官，例如腾讯马化腾、微信张小龙、百度李彦宏等等。产品经理需要思考打造什么样的产品才能达成公司的战略或战术目的，他要综合考虑产品是否满足功能、质量和商业等需求，满足功能需求只能达到及格线，易用性、交互体验、性能、可靠性等质量需求能否满足才是产品达到优秀的关键，以及从商业角度考虑选择什么时机将产品推向市场，有节奏地推动用户和业务的不断增长等。 任何技术都是服务于业务的，架构主要是承上启下的作用，架构设计需要将老板和产品的战略战术规划跟开发实现衔接起来，例如

REST 的架构设计与实现 　　REST（Representational State Transfer）是一种轻量级的Web Service架构风格，其实现和操作明显比SOAP和XML-RPC更为简洁，可以完全通过HTTP协议实现，还可以利用缓存Cache来提高响应速度，性能、效率和易用性上都优于SOAP协议。 　　REST架构遵循了CRUD原则，CRUD原则对于资源只需要四种行为：Create（创建）、Read（读取）、Update（更新）和Delete（删除）就可以完成对其操作和处理。这四个操作是一种原子操作，即一种无法再分的操作，通过它们可以构造复杂的操作过程，正如数学上四则运算是数字的最基本的运算一样。 REST架构让人们真正理解我们的网络协议HTTP本来面貌，对资源的操作包括获取、创建、修改和删除资源的操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法: 1) 使用HTTP POST方法去创建 资源 2) 使用HTTP GET方法去读取 资源 3) 使用HTTP PUT 方法去更新 资源 4) 使用HTTP DELETE方法去删除 资源 因此REST把HTTP对一个URL资源的操作限制在GET、POST、PUT和DELETE这四个之内。这种针对网络应用的设计和开发方式，可以降低开发的复杂性，提高系统的可伸缩性。 　　 REST 的设计准则 　

模式 是针对特定上下文中发生的问题的可重用解决方案。这个想法起源于现实世界中的建筑架构设计，并且已被证明针对软件架构设计同样行之有效。 常用的模式结构包括：1、需求 2、结果上下文 3、相关模式 对于大型和复杂的应用程序，微服务架构往往是最佳的选择。然后，除了拥有正确的架构之外，成功的软件开发还需要在组织、开发和交付流程做一些工作。 解决方法之一是：把大团队拆分成一系列小团队，每个团队都足够小，有一个明确的职责。每个团队都是跨职责的，可以独立完成开发、测试和部署等任务，而不需要频繁与其他团队沟通或者协调。 持续交付：能够以可持续的方式安全、快速地将所有类型的更改（包括新功能、配置更改、错误修复和实验）交付到生产环境或用户手中。 总结： 单体架构模式应用程序构建为单个可部署单元 微服务架构模式将系统分解为一组可独立部署的服务，每个服务都有自己的数据库 单体架构是简单应用的不错选择，微服务架构通常是大型复杂应用的更好选择 微服务架构使小型自治团队能够并行工作，从而加快软件开发的速度 微服务架构不是银弹，它存在包括复杂性在内的诸多弊端 微服务架构模式语言是一组模式，可帮助使用微服务架构构建应用程序，它可以帮助你决定是否使用微服务架构，如果你选择微服务架构，模式语言可以帮助你有效地应用它 来源： CSDN 作者： 我是小小小蟋蟀 链接： https://blog.csdn.net/xyz

架构设计（1）-谈谈架构 原创我为AI领域做了奉献 发布于2018-11-15 10:39:22 阅读数 419 收藏 展开 分享一下我老师大神的人工智能教程！零基础，通俗易懂！http://blog.csdn.net/jiangjunshow 也欢迎大家转载本篇文章。分享知识，造福人民，实现我们中华民族伟大复兴！ 1、什么是架构和架构本质 在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。 LInux有架构，MySQL有架构，JVM也有架构，使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构，应该关注哪一个？想要清楚以上问题需要梳理几个有关系又相似的概念：系统与子系统、模块与组建、框架与架构: 1.1、系统与子系统 系统：泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能独立完成的工作能力的群体。 子系统：也是由一群关联的个体组成的系统，多半是在更大的系统中的一部分。 1.2、模块与组件 都是系统的组成部分，从不同角度拆分系统而已。模块是逻辑单元，组件是物理单元。 1.3、框架与架构 框架是组建的规范，例如：MVC、MVP、MVVM等，是提供基础功能的产品，例如：Ruby on Rails、Spring、Laravel、Django等。 框架是规范，架构是结构。 我再这重新定义架构

MVC实用架构设计（二）——使用MEF应用IOC（依赖倒置） 前言 　　在《 上篇 》中，基本的项目结构已经搭建起来了，但是有个问题，层与层之间虽然使用了接口进行隔离，但实例化接口的时候，还引入了接口实现类的依赖。如下图： 　　 面向接口编程 ，Controller应该只依赖于站点业务层的接口，而不能依赖于具体的实现，否则，就违背了在层之间设置接口的初衷了。 　　另外，如果上层只依赖于下层的接口，在做单元测试的时候，就可以用 Moq ， Fakes 等Mock工具来按实际需求来模拟接口的实现，就可以灵活的控制接口的返回值来对各种情况进行测试，如果依赖于具体的实现，项目的可测试性将大大减小，不利于进行自动化的单元测试。 　　要不依赖于具体的实现，就不能使用通常的 T t = new T() 的方式来获得一个类的实例了，需要通过IOC容器来对对象生命周期，依赖关系等进行统一的管理。 MEF的优势 　　.net中可用的IOC容器非常多，如 CastleWindsor，Unity，Autofac，ObjectBuilder，StructureMap，Spring.Net等，这些第三方工具各不相同，但功能大体都相同，大都需要事先对接口与实现进行配对（通过代码或配置文件），然后由系统自动或手动来通过接口来获得相应实现类的实例，对象实例化的工作由IOC容器自动完成。 　

业界软件架构设计的方法论很多，各有各自的应用场景和特点，下文结合ADMEMS（Architecture Design Method has been Extended to Method System）架构设计方法论说明软件架构的过程： 架构阶段 目标 方式方法 现实工作场景 预架构阶段 全面理解需求；需求结构化，摒弃“需求列表”，建立二维需求观（ADMEMS矩阵）。 使用ADMEMS矩阵方法，捋清需求间关系和发现衍生需求。 1、与人：与项目经理、需求分析师等内部需求人员了解需求；与客户了解需求（不建议架构师做需求分析师角色）。 2、与物：了解《需求规格说明书》等需求文档。" 3、对需求有什么问题，反馈给售前或销售，可能会参与拜访客户或电话会议。 4、销售或售前有时会要求提供一个大致的工作量，以便他们初步评估项目可行性。 概念架构 高层组件及其关系 1、初步设计，基于关键功能，借助鲁棒图进行以发现职责为目的的初步设计（不是必须）。 2、高层分割，将复杂系统切分为多个二级系统或多个子系统。 3、考虑非功能需求，采用ADMEMS推荐的目标-场景-决策表。 1、参与内部讨论：项目可行性分析、讨论，从需求、技术、人力、风险等角度提供建议。 2、项目投标准备：参与投标团队的技术方案编写，编写系统架构章节，解决招标书上技术问题的问答。 3、参与项目讲标：作为讲标团队成员参与项目讲标

本文首发于 vivo互联网技术 微信公众号 链接： https://mp.weixin.qq.com/s/npRRRDqNUHNjbybliFxOxA 作者：刘延江 近年来，随着IT技术与大数据、机器学习、算法方向的不断发展，越来越多的企业都意识到了数据存在的价值，将数据作为自身宝贵的资产进行管理，利用大数据和机器学习能力去挖掘、识别、利用数据资产。如果缺乏有效的数据整体架构设计或者部分能力缺失，会导致业务层难以直接利用大数据大数据，大数据和业务产生了巨大的鸿沟，这道鸿沟的出现导致企业在使用大数据的过程中出现数据不可知、需求难实现、数据难共享等一系列问题，本文介绍了一些数据平台设计思路来帮助业务减少数据开发中的痛点和难点。 本文主要包括以下几个章节: 本文第一部分介绍一下大数据基础组件和相关知识。 第二部分会介绍lambda架构和kappa架构。 第三部分会介绍lambda和kappa架构模式下的一般大数据架构 第四部分介绍裸露的数据架构体系下数据端到端难点以及痛点。 第五部分介绍优秀的大数据架构整体设计 从第五部分以后都是在介绍通过各种数据平台和组件将这些大数据组件结合起来打造一套高效、易用的数据平台来提高业务系统效能，让业务开发不在畏惧复杂的数据开发组件，无需关注底层实现，只需要会使用SQL就可以完成一站式开发，完成数据回流，让大数据不再是数据工程师才有的技能。 一

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本文首发于 vivo互联网技术 微信公众号 链接： https://mp.weixin.qq.com/s/npRRRDqNUHNjbybliFxOxA 作者：刘延江 近年来，随着IT技术与大数据、机器学习、算法方向的不断发展，越来越多的企业都意识到了数据存在的价值，将数据作为自身宝贵的资产进行管理，利用大数据和机器学习能力去挖掘、识别、利用数据资产。如果缺乏有效的数据整体架构设计或者部分能力缺失，会导致业务层难以直接利用大数据大数据，大数据和业务产生了巨大的鸿沟，这道鸿沟的出现导致企业在使用大数据的过程中出现数据不可知、需求难实现、数据难共享等一系列问题，本文介绍了一些数据平台设计思路来帮助业务减少数据开发中的痛点和难点。 本文主要包括以下几个章节: 本文第一部分介绍一下大数据基础组件和相关知识。 第二部分会介绍lambda架构和kappa架构。 第三部分会介绍lambda和kappa架构模式下的一般大数据架构 第四部分介绍裸露的数据架构体系下数据端到端难点以及痛点。 第五部分介绍优秀的大数据架构整体设计 从第五部分以后都是在介绍通过各种数据平台和组件将这些大数据组件结合起来打造一套高效、易用的数据平台来提高业务系统效能，让业务开发不在畏惧复杂的数据开发组件，无需关注底层实现

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 前几天被人问如何做架构设计，当时准备不足，回答的不理想，所以想在这里把自己对架构设计的思考梳理一下。 作为一个程序员，我对编程有基本的信念：代码首先是给人阅读，然后顺便让机器运行。基于这个信念形成了我对设计的思考。如果你不认同这点，那么后面就没有必要看了。 首先，命名非常重要。某名宿说过，命名是计算机世界中最重要的两件事之一（另一件事是缓存）。做设计首先要取名，名字能够代表系统的职责和功能，体现你对问题本质的理解。模块的设计、类的设计、接口设计、函数设计也一样。系统中每个逻辑单元都应该有清晰的名字，如果你发现命名很难或者需要很多单词组合，那就说明你的设计出了问题：职责太多或者不够清晰。 第二，设计的本质是管理复杂度。业务本身的复杂度无法降低，但是可以把复杂的业务分解为很多较简单的子问题，然后再对子问题进行设计。对系统的分解需要遵循两个原则：1、分解后的子系统应该在逻辑上属于同一个层级；2、子系统在逻辑上应该彼此独立，互不影响。 大家基本都会做分解，但是分解的结果差别很大，主要是由于视角的区别。在我最开始做架构的几年，主要从技术视角考虑怎么做分解（追求代码的复用），设计很精巧，但是后期可维护性差。现在我会更多从业务视角出发（业务本身包含哪些部分，各部分是什么关系），不刻意追求复用，后期的可维护性很不错

　　在前面的文章里我谈到了前后端分离的一些看法，这个看法是从宏观的角度来思考的，没有具体的落地实现，今天我将延续上篇文章的主题，从纯前端的架构设计角度谈谈前后端分离的一种具体实现方案，该方案和我原来设想有了很大的变化，但是核心思想没变，就是控制层是属于Web前端的。 　　在以前文章里我说道前后端分离的核心在于把mvc的控制层归为前端的一部分，原方案的构想在实际的生产开发里很难做到，我觉得核心还是控制层和视图层的技术异构性，这样后果使得系统改造牵涉面太大，导致在项目团队里，沟通、协调以及管理成本相对较高，随着前端技术的发展，前端开发的工程量是越来越大，难度也是越来越高，因此前端工程的项目化，工程化和独立性越来越被人重视了，所以出现了大量的javascript MVC的富应用。如果javascript也能做到MVC模式，那么前端框架就可以抛弃异构语言的控制层，做到真正的独立。 　　要把传统的ＭＶＣ的Ｃ层从前端剥离掉，我们首先要理解下ＭＶＣ的Ｃ层即控制层到底做了什么样的事情，控制层的作用是模型层和视图层沟通的纽带，模型层进一步具体点就是数据层，视图层具体点就是数据展示给用户的方式，下面我们看看java的Web应用里，控制层和视图层是如何耦合的呢？做过java的web开发的人第一个反应就是页面里回嵌入大量java代码或者使用jsp的标签或者使用velocity