架构

烧脑！CMU、北大等合著论文真的找到了神经网络的全局最优解 机器之心 ​ 已认证的官方帐号 811 人赞同了该文章 选自arXiv，作者：Simon S. Du、Jason D. Lee、Haochuan Li、Liwei Wang、Xiyu Zhai，机器之心编译，参与：思源、王淑婷、张倩。 一直以来，我们都不知道为什么深度神经网络的损失能降到零，降到零不代表着全局最优了么？这不是和一般 SGD 找到的都是局部极小点相矛盾么？最近 CMU、北大和 MIT 的研究者分析了深层全连接网络和残差网络，并表示使用梯度下降训练过参数化的深度神经网络真的能找到全局最优解。 用一阶方法训练的神经网络已经对很多应用产生了显著影响，但其理论特性却依然是个谜。一个经验观察是，即使优化目标函数是非凸和非平滑的，随机初始化的一阶方法（如随机梯度下降）仍然可以找到全局最小值（训练损失接近为零），这是训练中的第一个神秘现象。令人惊讶的是，这个特性与标签无关。在 Zhang 等人的论文 [2016] 中，作者用随机生成的标签取代了真正的标签，但仍发现随机初始化的一阶方法总能达到零训练损失。 人们普遍认为过参数化是导致该现象的主要原因，因为神经网络只有具备足够大的容量时才能拟合所有训练数据。实际上，很多神经网络架构都高度过参数化。例如，宽残差网络（Wide Residual Network）的参数量是训练数据的

MVC的架构和多层架构，在ORM框架上是不兼容的。MVC的数据库操作需要通过实体框架Entity Framework，多层的数据库操作需要通过DAL层。我们最近刚完成的项目，实现了MVC和多层的并存，有一些心得，记述一下。 为什么硬要把MVC和多层捆在一起用？有三个原因，首先，新的项目是一个站长工具网站( www.youhuafenxi.com )，里面很多查询算法，我们在BLL层里都有积累，可以直接拿来用；其次，MVC的优雅和干净，特别适合我们这个网站；最后，新技术的探索和使用永无止境，不学习就会落后。 整体项目如下： 经过考虑，我决定数据操作走多层，放弃Entity Framework。原因在于：1 团队成员很少接触Entity Framework，本来Mvc已经是新东西了，再引入Entity Framework，这次项目中的新东西有点太多，风险过高。我一向觉得一个项目中新东西比例不宜超过30%；2 据我用过的朋友说，Entity Framework性能不太好，当然这个有待实际核实；3 BLL是个公用层，我们写在BLL层里的代码将来还可以被别的项目复用，而Entity Framework写的代码一般只能被本项目使用。 MVC架构，数据实体是Models这个目录： 多层的数据实体是Model层： 这两种Model有什么差别呢？多层的Model，是完全和数据库字段一一对应的，很简单

前言 最近这一段时间由于Nodejs的逐渐成熟和日趋稳定，越来越多的公司中的前端团队开始尝试使用Nodejs来练一下手，尝一尝鲜。 一般的做法都是将原本属于后端的一部分相对于业务不是很重要的功能迁移到Nodejs上面来，也有一些公司将NodeJS作为前后端分离的一个解决方案去施行。而像淘宝网这类的大型网站也很早的完成了前后端的分离，给我们这样的后来者提供了宝贵的经验。 同样，我们的大网盘团队也早在去年早早就开始了紧锣密布的准备工作，这目前工作也做的差不多了，现在我就来总结一下在过程中遇到的坑点以及注意事项。 认识前后端分离 在传统的web应用开发中，大多数的程序员会将浏览器作为前后端的分界线。将浏览器中为用户进行页面展示的部分称之为前端，而将运行在服务器，为前端提供业务逻辑和数据准备的所有代码统称为后端。 由于前后端分离这个概念相对来说刚出现不久，很多人都是只闻其声，不见其形，所以可能会对它产生一些误解，误以为前后端分离只是一种web应用开发模式，只要在web应用的开发期进行了前后端开发工作的分工就是前后端分离。 其实 前后端分离并不只是开发模式，而是web应用的一种架构模式 。在开发阶段，前后端工程师约定好数据交互接口，实现并行开发和测试；在运行阶段前后端分离模式需要对web应用进行分离部署，前后端之前使用HTTP或者其他协议进行交互请求。然而作为一种架构模式

转自：http://www.ruanyifeng.com/blog/2011/09/restful.html 越来越多的人开始意识到，网站即软件，而且是一种新型的软件。 这种"互联网软件"采用客户端/服务器模式，建立在分布式体系上，通过互联网通信，具有高延时（high latency）、高并发等特点。 网站开发，完全可以采用软件开发的模式。但是传统上，软件和网络是两个不同的领域，很少有交集；软件开发主要针对单机环境，网络则主要研究系统之间的通信。互联网的兴起，使得这两个领域开始融合，现在我们必须考虑，如何开发在互联网环境中使用的软件。 RESTful架构，就是目前最流行的一种互联网软件架构。它结构清晰、符合标准、易于理解、扩展方便，所以正得到越来越多网站的采用。 但是，到底什么是RESTful架构，并不是一个容易说清楚的问题。下面，我就谈谈我理解的RESTful架构。 一、起源 REST这个词，是 Roy Thomas Fielding 在他2000年的 博士论文 中提出的。 Fielding是一个非常重要的人，他是HTTP协议（1.0版和1.1版）的主要设计者、Apache服务器软件的作者之一、Apache基金会的第一任主席。所以，他的这篇论文一经发表，就引起了关注，并且立即对互联网开发产生了深远的影响。 他这样介绍论文的写作目的： "本文研究计算机科学两大前沿----软件和网络

微核架构的本质是微核掌握了更多的上下文， 知道系统是由哪些要素怎么组成的。 知道怎么使用插件来（分步）完成整体的功能。 微核架构 = 整体上下文 + 配置组成 微核架构（microkernel architecture）又称为"插件架构"（plug-in architecture），指的是软件的内核相对较小，主要功能和业务逻辑都通过插件实现。 内核（core）通常只包含系统运行的最小功能。插件则是互相独立的，插件之间的通信，应该减少到最低，避免出现互相依赖的问题。 来源： https://www.cnblogs.com/feng9exe/p/12103182.html

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

从历史的角度来看，应用安全一度在应用交付中被忽视。这是因为将高标准的安全性整合到应用的各个环节中，需要大量时间去测试和迭代，这会大大降低应用的开发速度和增加成本预算。 Aone云注意到，随着企业不断优化和加速应用开发周期，越来越多的应用在公共云中交付，安全性就成了公有云应用不得不正视的巨大挑战。公有云上的应用通常在新架构中运行，这些新架构可以提供前所未有的效率、灵活性和成本效益。开发工具的流行，进一步加快了应用的开发和部署步伐， DevOps越来越多地在应用交付中发挥积极作用。自动化平台、强大的业务流程框架、开源工具包和可视方案等越来越多地在公有云环境中均扮演重要角色，这也为公有云引入新的安全风险。对应用的保护能力就会较差，进而不能对连续交付流程提供有保障的安全性。 云生态环境：容器、微服务和服务网格 越来越多的容器、微服务和服务网格出现在了公有云环境中。据Aone云所知，从单片架构过渡到微服务架构，使得企业更频繁地部署应用，以更可靠的方式独立交付不同的微服务。容器技术与微服务完美匹配。每个微服务都可以跨越多个容器部署，以实现快速弹性部署，既提高了应用质量又缩短上线时间。 服务网格在微服务体系结构中处理服务间通信的层级。其目的是通过负载平衡、遥测、流量路由、运行状况检查等提供弹性，以降低微服务体系结构的复杂性。 向微服务架构过渡的诸多挑战中有一些挑战与提供对象的规模有关。在单片时代

架构设计（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等。 框架是规范，架构是结构。 我再这重新定义架构

Kubernetes简介 此文旨在以简明清晰的方式简要介绍Kubernetes的缘由、原理和架构。读者需要对容器技术有所了解。 Kubernetes缘由 在传统的 PaaS上，用户必须为不同语言、不同框架区分不同的打包方式，这个打包过程是非常具有灾难性的。而现实往往更糟糕，当在本地跑的好好的应用，由于和远端环境的不一致，在打包后却需要在云端各种调试，最终才能让应用“平稳”运行。 Docker的出现改变了这一切，它凭借容器技术解决了这个问题，大大方便了交付、测试和部署应用。 然而，在Docker容器技术被炒得热火朝天之时，大家发现，如果想要将Docker应用于具体的业务实现，是存在困难的——编排、管理和调度等各个方面，都不容易。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。于是，人们迫切需要一套管理系统，对Docker及容器进行更高级更灵活的管理。 于是，Kubernetes（K8S）就出现了。 Kubernetes是Google开源的容器集群管理系统，能提供一个以“容器为中心的基础架构”。Kubernetes的目标是让部署容器化的应用简单并且高效。它支持自动化部署、大规模可伸缩、应用容器化管理。 简要原理 Kubernetes将资源高度抽象化，允许将容器化的应用程序部署到集群中。在新的部署模型中，应用程序被直接安装到特定的机器上

Hive 架构原理 架构图 Hive 通过用户提供的一系列交互接口,接收到用户的指令( SQL ) 使用自己的 Driver ,结合元数据( MetaStore ),将这些指令翻译成 MapReduce ,提交到 Hadoop 中执行 最后,将执行返回的结果输出到用户交互接口 运行机制 详细执行步骤 用户接口: Client CLI ( hive shell 命令行), JDBC/ODBC ( java 访问 hive ), WEB GUI (浏览器访问 hive ) 元数据: Metastore 元数据包括:表名,表所属数据库(默认是 default ) ,表的拥有者,列/分区字段,表的类型(是否是外部表),表的数据所在目录等。 默认 存储在自带的 derby 数据库中,推荐使用 MySQL 存储 Metastore hive 使用 HDFS 进行存储,使用 MapReduce 进行计算 驱动器: Driver 解析器( SQL Parser ) 将 SQL 字符转换成抽象语法树 AST ,这一步一般使用都是第三方工具库完成,比如 antlr ,对 AST 进行语法分析,比如表是否存在,字段是否存在, SQL 语句是否有误 编译器( Physical Plan ):将 AST 编译生成逻辑执行计划 优化器( Query Optimizer ):对逻辑执行计划进行优化 执行器(