架构

TensorFlow 是相对高阶的机器学习库，用户可以方便地用它设计神经网络结构，而不必为了追求高效率的实现亲自写 C++或 CUDA 代码。它和 Theano 一样都支持自动求导，用户不需要再通过反向传播求解梯度。 而基于 TensorFlow 的轻量级框架 AdaNet，可以使用少量专家干预来自动学习高质量模型。据介绍，AdaNet 在谷歌近期的强化学习和基于进化的 AutoML 的基础上构建，快速灵活同时能够提供学习保证（learning guarantee）。重要的是，AdaNet 提供通用框架，不仅能用于学习神经网络架构，还能学习集成架构以获取更好的模型。 结合不同机器学习模型预测的集成学习在神经网络中得到广泛使用以获得最优性能，它从其悠久历史和理论保证中受益良多，从而在 Netflix Prize 和多项 Kaggle 竞赛等挑战赛中取得胜利。但是，因其训练时间长、机器学习模型的选择要求领域专业知识，它们在实践中并不那么常用。而随着算力、深度学习专用硬件（如 TPU）的发展，机器学习模型将越来越大，集成技术也将越发重要。现在，想象一个工具，它能够自动搜索神经架构，学习将最好的神经架构集成起来构建高质量模型。 刚刚，谷歌发布博客，开源了基于 TensorFlow 的轻量级框架 AdaNet，该框架可以使用少量专家干预来自动学习高质量模型。AdaNet

引用说明：原文来自于 http://www.ibm.com/developerworks/cn/webservices/1010_wanghq_eda/1010_wanghq_eda.html ，为了方便本人阅读，文本格式略有调整。 EDA/SOA/ESB 的实践摘要 事件驱动架构 (Event-Driven Architecture，EDA) 面向服务架构 (Service-Oriented Architecture, SOA) 是一种 IT 架构策略，其基于面向服务的概念之上 企业服务总线（Enterprise Service Bus, ESB） 消息中间件（Message Oriented Middleware, MOM） 下图是一个证券公司股票交易系统的简图： 图 1. 证券公司股票交易系统概略图 从上图我们可以看出，整个应用被分为很多子系统，各个子系统之间存在着大量的信息交互。而且大部分应用输入都需要经历一个比较长的生命周 期，比如说一个客户订单输入到系统后，会先后经历前台系统 (Front Office)，中台系统 (Middle Office) 以及后台系统 (Back Office)，而且每个系统内部又包括很多服务组件。除了系统层面的跨度外， 这个生命周期也体现在时间长度上。而且，如今所有的金融系统都追求 STP (Straight Through

一、SOA介绍 面向服务的体系结构（英语：service-oriented architecture）是构造分布式计算的应用程序的方法。它将应用程序功能作为服务发送给最终用户或者其他服务。它采用开放标准、与软件资源进行交互并采用表示的标准方式。 企业系统的架构师认为SOA能够帮助业务迅速和高效地响应变化的市场条件。 服务导向的架构在宏观（服务）上，而不是在微观上（对象）因此提高了重复使用性。同时，服务导向的架构可以简化与传统系统的互连和使用。 SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、XML（标准通用标记语言的子集）/Web Service技术之后的自然延伸。 二、SOA的原则 以下指导原则是开发，维护和使用SOA的基本原则: 可重复使用, 粒度, 模组性, 可组合型, 物件化原件, 构件化以及具交互操作性。 符合开放标准(通用的或行业的)。 服务的识别和分类，提供和发布，监控和跟踪。 下面是一些特定的体系架构原则： 服务封装 服务松耦合(Loosely coupled) - 服务之间的关系最小化，只是互相知道。 服务契约 - 服务按照服务描述文档所定义的服务契约行事。 服务抽象 - 除了服务契约中所描述的内容，服务将对外部隐藏逻辑。 服务的重用性 - 将逻辑分布在不同的服务中

1 App后台入门 1.1 App后台的功能 （1）远程存储数据； （2）消息中转。 1.2 App后台架构 架构设计的流程 （1） 根据App的设计，梳理出App的业务流程； （2） 把每个业务流程可能会遇到的问题整理出来； （3） 根据整理出来的问题，探讨可行的技术解决方案； （4） 把所有的技术解决方案有机融合，就是一个App后台的初步架构。 架构设计的特点 （1） 架构是和业务紧密相关； （2） 架构的演变是由业务驱动； （3） 架构不是为了炫耀技术。 1.3 App和App后台的通信 （1） 用HTTP协议还是私有协议； （2） 用长连接还是短连接； （3） 通信数据格式（JSON、XML） 1.4 选择服务器 （1） 传统IDC； （2） 云服务器。 1.5 选择开发语言 （1） 不同语言有其擅长的业务场景和性能特性； （2） 考虑开发效率和运行效率； （3） 同一个项目不同业务逻辑可以用不同语言实现。 1.6 敏捷开发 （1） Sprint计划会议； （2） 迭代开发； （3） 每日例会； （4） 评审会议； （5） 回顾会议； （6） 及时反馈。 2 App后台基础技术 2.1 从业务逻辑提炼API接口 从业务逻辑到提炼API可分为下面6个阶段： （1） 业务逻辑思维导图； 根据需求抽象出业务逻辑。 （2） 功能-业务逻辑思维导图； 支撑业务逻辑的功能模块， （3）

本文将介绍微服务架构和相关的组件，介绍他们是什么以及为什么要使用微服务架构和这些组件。本文侧重于简明地表达微服务架构的全局图景，因此不会涉及具体如何使用组件等细节。 要理解微服务，首先要先理解不是微服务的那些。通常跟微服务相对的是单体应用，即将所有功能都打包成在一个独立单元的应用程序。从单体应用到微服务并不是一蹴而就的，这是一个逐渐演变的过程。本文将以一个网上超市应用为例来说明这一过程。 最初的需求 几年前，小明和小皮一起创业做网上超市。小明负责程序开发，小皮负责其他事宜。当时互联网还不发达，网上超市还是蓝海。只要功能实现了就能随便赚钱。所以他们的需求很简单，只需要一个网站挂在公网，用户能够在这个网站上浏览商品、购买商品；另外还需一个管理后台，可以管理商品、用户、以及订单数据。 我们整理一下功能清单： 网站 用户注册、登录功能 商品展示 下单 管理后台 用户管理 商品管理 订单管理 由于需求简单，小明左手右手一个慢动作，网站就做好了。管理后台出于安全考虑，不和网站做在一起，小明右手左手慢动作重播，管理网站也做好了。总体架构图如下： 小明挥一挥手，找了家云服务部署上去，网站就上线了。上线后好评如潮，深受各类肥宅喜爱。小明小皮美滋滋地开始躺着收钱。 随着业务发展…… 好景不长，没过几天，各类网上超市紧跟着拔地而起，对小明小皮造成了强烈的冲击。 在竞争的压力下

软件架构最佳实践、企业架构模式以及系统描述的正式方法都是非常重要且实用的工具，总会有合适的场景让它们发挥作用。但在设计系统时，请从简单始、以简单终，尽可能避免一切会无谓提高复杂度的架构与正式工具。 我的职责是设计和构建大型系统。我参与重写了 Uber 的分布式支付系统，设计并交付了 Skype on Xbox One，开源了 Uber 的移动架构框架 RIBs 。所有这些系统都进行了彻底的设计，经过多次迭代和大量讨论。然后，这些设计被记录到设计文档中，在我们开始构建之前分发出去，从而获得更多的反馈。 所有这些系统的规模都很大：有数百名开发人员在构建它们——或者以它们为基础进行构建——并且它们支撑着每天数百万人使用的系统。它们不仅仅是绿地项目。重写的支付系统就是用于替换两个已有的支付系统，有几十个系统、数十个团队在使用它们，但所有这些都没有对业务产生任何影响。重写 Uber App 是一个由数百名工程师同时参与的项目，他们将现有的功能移植到一个新的架构中。 让我先说些可能会让你觉得吃惊的事。 首先，这些设计都没有使用任何标准的软件架构规划工具。 我们没有使用 UML ，没有使用 4+1 模型，没有使用 ADR ，也没有使用 C4 和依赖关系图。我们创建了大量的图表，但是没有遵循任何严格的规则。只是使用了普通的方框和箭头，类似于这个描述信息流的图或这个概括类结构和组件之间关系的图

技术架构，是将产品需求转变为技术实现的过程。技术架构解决的问题包括了如何进行纯技术层面的分层、开发框架选择、语言选择（这里以 JAVA 语言为主）、涉及到各自非功能性需求的技术点（安全、性能、大数据）。技术架构是确定组成应用系统实际运行的技术组件、技术组件之间的关系，以及部署到硬件的策略。 技术架构面临最大的挑战是“不确定性”。在技术架构上，很多时候就会面临这种选择。是要选择业界最新的技术？还是选择团队最熟悉的技术？如果选择最新的技术，遇到新技术出了问题怎么解决？如果选择目前熟悉的技术，后续技术演进怎么办？这些都是架构师在做技术架构过程中需要考虑的。 业务在千变万化、技术在层出不穷，没有一套通用的技术架构模式来适用所有的系统。那么，我们如何保证在做技术架构时，能够实现一个稳定、出色的系统。面对这些“不确定性”时的架构设计问题，这里从战略和战术两个层面来提供一些设计原则。战略层提供的是技术架构的方法和思路，属于顶层设计；战术层提供的是技术架构的技术实践方式，更偏向详细设计。 战略层设计原则 战略层的设计原则就是：合适原则、简单原则、演化原则。 1.1 合适原则 技术人员有一种很强的技术情怀，就是在做设计的过程中，很希望挑战新的技术、在项目中采用最新的框架、或者自己重造一个比业界的还要牛的轮子。这样才能够显示出自己的优秀，以至于不让自己显的那么平庸。比如

在上一篇博客中（ 浅谈微服务架构与.Net Core ）我们谈到微服务架构与.Net Core，大体分析了下微服务架构的一些优势，在这边博客中，将谈谈架构设计的一些理念。 首先，代码要清晰明了，层次分明，模块间耦合度要尽量降低，代码并不是要越复杂越好，可能有人认为，代码写得越复杂、算法用的越高级，让别人越看不懂就越牛X，我认为恰恰相反，代码越是简单就能实现的就尽量做到简单，能用几行代码能解决的问题何必要写个牛X的算法来实现呢？ 其次，能做到通用的模块需要单独提炼出来，不要在其他业务逻辑中混合实现，不利于代码的移植，以下简单说说常用的一些模块或逻辑需要特别注意的； 1、底层数据访问需要单独写，当我们数据库发生变化，比如我们这个项目用的是SqlServer，下个项目用的是MySQL，要做到很轻易的切换； 2、缓存管理需要独立出来，通常，我们开发都会用到缓存技术，能把缓存用好，系统性能也会得到大幅度提升，简单举个例子，比如我们开发一个系统，用的是MemoryCache，但是系统上线运行一段时间后，并发量增大，本机缓存已经不能满足需求，我们需要对系统进行集群，减轻服务器压力，此时需要用Redis来管理缓存，那么此时，我们需要做到很容易的从MemoryCache切换到Redis来做缓存管理，我们只需要改一下配置文件就能达到预期效果而不必在用到缓存的地方一个一个的去改再编译上线。 3

《基于大中台小前台模式设计高并发电商架构》 --- 学习笔记 1. 什么是大中台？ 大中台 中台是一种 组织机制 和 业务机制 在 公司组织架构层面 通过组织架构调整，物理拆分独立的中台部门 在 公司业务层面 通过吧公共恩能够力下沉为服务，并做好服务连接，赋能业务部门 大中台组织架构调整 阿里的组织架构 大中台业务架构调整 　　公司交付物 　　产品 　　业务架构（OLTP） 　　个性化业务架构 　　 公共业务架构 　　数据架构（OLAP） 　　个性化数据架构 　　 公共数据架构 　　技术架构 　　 技术支撑 　　02 什么是小前台 　　　　小前台 　　组织架构：业务部门 　　业务服务：个性化的业务服务 03 大中台小前台模式适用场景 04 业务大中台小前台电商架构如何设计实践 　　业务大中台小前实践 　　在公司业务层面通过把公共下沉为服务，并做好服务连接，赋能业务部门 　　公共能力下沉为服务 做好公共能力下沉服务的全连接，使得小前台业务一键接入 业务大中台小前台实践： 　　个性化数据存储在中台 　　公共数据表+业务个性化扩展数据表 来源： https://www.cnblogs.com/Edward-Wang/p/11801180.html

**架构设计，必须有明确的目标和宗旨。 **这是我长久以来的观点。 今天很幸运看到这两则文章，非常认同作者的观点。 这两则文章把架构设计的目的阐述得很精准，我将链接保存、分享至此： 架构之路（一）：目标 架构之路（二）：性能 以下是我从中摘选的一段： “架构的一个天然目的就是：让代码更智能, 让程序员更傻瓜。换个说法就是：架构要‘创造便利，让程序员更关注业务’。” “这可能是一个让程序员感到悲哀的事实。正如机械师不停的发明，让机器变得越来越聪明，取代流水线上的工人，最终取代了他自己。**从某种意义上说，我们都是自掘坟墓的人。**一个良好的架构，就应该让每一个普通的开发人员，都是一个廉价的、随时可以被替换的螺钉，这样才能保证整个系统永远健康的运行下去。” 来源： oschina 链接： https://my.oschina.net/u/2321528/blog/535544