架构

   今天，中台已经成为架构转型的里程碑，从互联网到传统企业谈架构必有中台。虽然各种中台概念层出不穷，但“数据中台”和“业务中台”作为中台概念的起始源头，被视为最纯正的中台，也是企业架构转型的重要目标。我所在的银行正筹备“数据中台”的建设，为此在内外部组织了多次技术研讨，每个人都有不同的想法，共同点仅限于希望自己的解决方案命名为“数据中台”。我想这种认识的差异是源于“数据中台”尚处在概念萌芽期，需要更多探讨与碰撞。本文借鉴了互联网公司和两家同业银行的案例，尝试对“数据中台”建设思路进行总结，所提出的架构方案仅供探讨，尚未应用于实际系统建设。 一、传说与误解     在争论什么是“数据中台”前，我们应该意识到“数据中台”只是解决方案，关键在于通过“数据中台”解决什么问题？在我看来，中台要解决的核心问题是在短时间内搭建或变更前台系统，从而快速响应用户需求、把握市场机会。     首先我们梳理下有关“中台”的传说。     作为这一波“中台”概念的源头，第一个传说必须来自阿里。“游戏公司”的传说，大致是这样，阿里的马老师带队参观了一家厉害的游戏公司 Supercell，它有很多成功的游戏产品，其独特优势是能够快速推出新产品，而依靠的就是中台系统。马老师受到了启发，回到阿里开始推进中台建设，在组织架构层面成立了单独的中台部门即“共享业务事业部”，系统层面建设了用户中心

基础知识 1、分布式基础理论 1.1、什么是分布式系统？ 分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统， 分布式系统（distributed system）是建立在网络之上的软件系统。 随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构无法应对， 分布式服务架构以及流动计算架构势在必行，需**一个治理系统**确保架构有条不紊的演进 1.2、发展演变 1.2.1 单一应用架构 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。 适用于小型网站，小型管理系统，将所有功能都部署到一个功能里，简单易用。缺点： 1、性能扩展比较难 2、协同开发问题 3、不利于升级维护 1.2.2 垂直应用架构 当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成不相干的几个应用,以提升效率,此时,用于加速前端页面开发的Web框架(MVC)是关键。 通过切分业务来实现各个模块独立部署，降低了维护和部署的难度， 团队各司其职更易管理，性能扩展也更方便，更有针对性。 缺点：公用模块无法重复利用，开发性的浪费 1.2.3 分布式服务架构 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来， 作为独立的服务，逐渐形成稳定的服务中心，

OSS架构 OSS全称是Open Sound system，叫做开放式音频系统，这种早期的音频系统是基于文件系统的访问方式，这意味着对声音的操作完全可以像对普通文件那样执行open，read等操作。OSS中，主要提供了一下几种音频设备的抽象设备文件： /dev/mixer：用来访问声卡中的混音器，用于调整声音大小和选择音源。 /dev/dsp、/dev/audio：读取这个设备就相当于录音，写这个设备就相当于放音。 ALSA架构 由于OSS设计上的缺陷，导致对混音的支持不好，再叫上2002年以后，OSS成为商业不开源软件，这就催生了Linux下另一种音频系统ALSA的出现，ALSA全称是Advanced Linux Sound Architecture，叫做Linux系统高级音频架构，它主要为声卡提供的驱动组件，以替代原先的OSS。ALSA架构借助于如下设备文件工作： /dev/pcmCODOc:用于录音的pcm设备 /dev/pcmCODOp:用于播放的pcm设备 /dev/timer:定时器 /dev/controlCO:用于声卡的控制，如通道选择 /dev/mixer:混音处理 声卡驱动集成 make menuconfig ARCH=arm device drivers-><*>Sound card support-><*>Advanced linux sound

本文内容大纲： 1、轻量级图形渲染引擎与应用 2、渲染引擎演进与优化之路 3、渲染引擎未来的发展方向 GCanvas 的定位是遵循 w3c 标准的跨平台的轻量级图形渲染引擎。有清晰的定位和目标，并且紧贴现有的业务，为业务提供丰富表现形式。 GCanvas 发展 GCanvas 引擎从早期的 H5 性能加速，到 Weex 业务落地，从小游戏的业务探索，到服务端渲染，再到小程序。经过几个阶段的发展后日渐成熟。 淘系无线架构的不断升级迭代，GCanvas 随之保持着更新迭代的步调，在多个业务场景中使用，了解下一些应用案例。 应用案例 GCanvas 的目标人群是业务开发者，满足业务的功能需求，对开发者也非常友好，尤其是前端开发者。熟悉 H5 Canvas 的同学，很容易上手，无任何学习成本。 Weex 2017年双十一预热会场，GCanvas 与魔影合作的版头动画 天猫未来店 天猫未来店的智能电子标签，基于 GCanvas JSBinding 的智能电子标签 小游戏 野生小伙伴，基于GCanvas小游戏应用 Sketch Render Demo+ 中的 Sketch Render ，基于 GCanvas 实现的服务端渲染 Sketch 文件 支付宝小程序/淘宝商家应用Canvas 基于支付宝小程序/淘系商家应用同层渲染组件 支付宝小程序诸葛找房 - 2D 淘宝商家应用AR试妆 -

spymemcached 深入分析 author ：智深 version ： 0.7 日志： http://my.oschina.net/astute QQ ： 2548921609 ( 技术交流 ) 一、简介 spymemcached 是一个 memcache 的客户端， 使用 NIO 实现 。 分析 spymemcached 需要了解 NIO ， memcached 使用， memcached 协议，参考资料中列出了有用的资源连接。 NIO 是 New I/O 的缩写， Java 里边大家一般称为异步 IO ，实际上对应 Linux 系统编程中的事件驱动 IO （ event-driven IO ），是对 epoll 的封装。其它的 IO 模型还包括同步，阻塞，非阻塞，多路复用（ select ， poll ）。阻塞 / 非阻塞是 fd 的属性，同步会跟阻塞配合，这样的应用会一直 sleep ，直到 IO 完成被内核唤醒；同步非阻塞的话，第一次读取时，如果没有数据，应用线程会立刻返回，但是应用需要确定以什么样的策略进行后面的系统调用，如果是简单的 while 循环会导致 CPU 100% ，复杂的类似自旋的策略增加了应用编程的难度，因此同步非阻塞很少使用。多路复用是 Linux 早期的一个进程监控多个 fd 的方式，性能比较低，每次调用涉及 3 次循环遍历，具体分析见 http

如何理解多租户架构？ 引用： https://www.cnblogs.com/pingfan21/p/7478242.html 　　 前段时间公司产品进行了架构的进化，进化到了多租户架构。当我第一次听到多租户时，我也挺纳闷，不理解。但当我逐渐的翻阅资料，以及研发功能时。不断的加深了对多租户的理解。尽管我现在也只是浅浅的懂一点而已。 　　OK,Let's get this straight（让我们搞懂它），接下来让我们问自己几个问题: 　　1.什么是多租户架构？ 　　2.多租户架构的优缺点？ 　　3.多租户架构的适用场景？ 　　让我们带着这几个问题进入下面的阅读。 一、对多租户的理解 　　多租户定义：多租户技术或称多重租赁技术，简称SaaS，是 一种软件架构技术 ，是实现如何在 多用户环境下（此处的多用户一般是面向企业用户）共用相同的系统或程序组件 ，并且可 确保各用户间数据的隔离性 。简单讲：在一台服务器上运行单个应用实例，它为多个租户（客户）提供服务。从定义中我们可以理解：多租户是一种架构，目的是为了让多用户环境下使用同一套程序，且保证用户间数据隔离。那么重点就很浅显易懂了， 多租户的重点就是同一套程序下实现多用户数据的隔离 。对于实现方式，我们下面会讨论到。 　　在了解详细一点：在一个多租户的结构下，应用都是运行在同样的或者是一组服务器下，这种结构被称为“单实例”架构

最近小组内代码review，遇到很多同事都讲不清楚需求的实现方案。 大概有以下几种表现： 上来不说需求，直接说代码实现。台下一头雾水，根本不知道设计方案是否合理。 描述完需求后，又直接看代码，看表结构，没有交代流程。 比较简单的算法，描述的特别绕，让人听不懂。被别人指出后，觉得这东西这么简单，你们为什么听不懂，还很委屈。 直接说术语，不给解释。还有自己造术语不给解释的，更混乱的是「复用」已有的术语，让大家理解都不同。 那么程序员如何把技术方案讲清楚呢？下面从实用的角度教大家一些小技巧，在短时间内具备讲清楚的能力。 一、要先交代需求背景 为什么要做这个需求，对于实现的要求是什么，产品经理提了哪些边界条件。没有银弹，一个技术方案的好坏与实现要求息息相关，是不能脱钩的。例如，一个接口访问质量统计系统，可以接受一天跑一次脚本生成数据。但是为用户提供服务的消费明细，肯定要能实时展示，并且不能出错。 在评审中，消耗时间比较多的，就是台下的听众问被评审人需求背景。还有台下的人给出了某个建议，然后被被评审人否定，说有个产品的要求我刚才没说。这时对提出建议的人来说，是很伤的。 交代好背景并对齐，是评审技术方案和代码review的基础，否则别人不知道你后面的是否合理，甚至不知道你到底在做什么。技术方案评审就无从谈起了。 二、介绍技术方案整体架构 背景知识说完后，说你的做法。要先总后分

我们可以使有dotnetcore跨平台的特性，优雅的实现在dotnetcore执行shell (bash). 代码如下: using System; using System.Collections.Generic; using System.Text; namespace hshoc { using System.Diagnostics; public static class ShellHelper { public static string Bash(this string cmd) { var escapedArgs = cmd.Replace("\"", "\\\""); var process = new Process() { StartInfo = new ProcessStartInfo { FileName = "/bin/bash", Arguments = $"-c \"{escapedArgs}\"", RedirectStandardOutput = true, UseShellExecute = false, CreateNoWindow = true, } }; process.Start(); string result = process.StandardOutput.ReadToEnd(); process.WaitForExit();

一、基本信息： 标题： 基于B/S模式的高校党务信息管理系统的设计与实现 时间：2019 来源：知网 关键词：党务管理 二、阅读内容： B/S结构模式： B/S结构模式（浏览器服务器模式），该模式是技术兴起后的一种网络结构模式，浏览器是客户端的应用软件。该模式统一了客户端，将系统功能实现的核心部分转移到了服务器端，使系统的开发、维护和使用得到了简化。采用此架构的应用系统的优点是：维护和升级方便。当前，由于客户的需求不断变更，软件系统的改进和升级也越发频繁，架构的软件产品则体现着更为方便的特性。传统的或客户服务器模式）模式，如果要进行软件的维护和升级，系统管理员不仅要更新服务器端程序，还要更新客户端程序，并且客户端程序还可能因为操作系统的兼容性问题，出现安装不了或提交不了请求等各种各样的问题。如果是在一个有成百上千部电脑的单位，让系统管理员来回奔跑进行维护，这样的工作效率是可想而知的。而B/S架构的软件只需要维护好服务器就行了，客户端通过WEB浏览器访问服务器，不需要对客户端做任何维护。无论用户的规模有多大，有多少分支机构都不会增加任何维护升级的工作量，所有的操作只需要针对服务器进行;这种“瘦”客户端，“胖”服务器端的设计是将来信息化发展的主流方向。软件升级和维护会越来越容易，而使用起来会越来越简单，从而节省了人力、物力、时间和费用。 (2)成本降低，选择更多。基于B

从几幅架构图中偷得半点海量数据处理经验 （注： 本文只是简简单单的截几幅图而已，要想更深入的学习和了解hadoop框架和mapreduce模式，或者对淘宝的数据魔方感兴趣的话，尽可参考此文： 从Hadhoop框架与MapReduce模式中谈海量数据处理 。） 最近对海量数据处理发生了不小的兴趣，特此从一些精彩文章中摘取几幅精彩的图片或片段，拿来给大家分享。所谓奇文共欣赏，好Architecture共品之。至于各位能从图中是窥得半点经验，还是一图以窥全貌，则不在我之责任，全在于读者怎么去解读这几幅精彩的架构图了。 所以，本文在选取一些架构图之后，只配以最简单的文字，个中内容，读者自行品味之。如果有任何问题或建议，欢迎不吝指正或畅所欲言。谢谢。 1、淘宝海量数据产品技术架构 上图是淘宝的数据魔方。按照数据的流向来划分，淘宝的数据产品的技术架构分为五层（如上图所示），分别是数据源、计算层、存储层、查询层和产品层（图摘自《程序员》8月刊）。 2、搜索引擎架构图 3、Facebook架构 3.1、架构概览 设计原则 尽可能的使用开源软件，并且在需要优化的时候进行优化 Unix 哲学。包括，模块化原则；整合化原则；清晰化原则等 任何组件具备扩展性；最小化故障影响；简化，简化，简化（本段文字摘自DBA nots）。 3.2、Facebook NewsFeed 的架构示意图 3.3