架构

工欲善其事，必先利其器。 N多年前微软官网曾发了 .Net下必备的十种工具 ，N多年过去了，世异时移，很多东西都已经变化了，那个列表也似乎陈旧了。而且，该文也只是对十种工具独立的介绍，显得有些罗列的感觉，是不是每个工具都是同等重要，工具与工具之间是否有联系？等等，阐述得并不明确。 这里，我想从另一个角崖，重新归纳一个更新的更实际的武器库。更新，是因为有很多最近几年才出来的工具/框架库，更实际，是因为我自己的项目就完全依赖使用。 Visual Studio 这个似乎是不言而喻的，只是从严谨的角度，也列在这。实际上，现在也有一个开源的IDE开发环境发展也不错，叫 SharpDevelop 。我并没有仔细看，不敢妄评。而我因要用到之后会讲的Resharper，也迫使我只能用VS。 Resharper ---重构必备 无论是从其名称，还是实际功能，Resharper绝对称得上利器，一旦你用熟了你就再也离不开它了。我去年换工作，很大一部分原因就是因为原单位不让我使用Resharper。几个面试，我也总在重复提出我这一要求。直至最新版本6.1为止，Resharper已经是个多面手。早期，它还只是个重构的工具，如今它是反编译器(原来的Reflector.Net就用不上了)，还是个代码审查工具(代码规范审查)，还是代码生成器(Code Smith又用不上了)，最后，它对键盘快捷键的组织使用

“架构的视角每个人都不一样，这位在eBay、携程、唯品会等平台型互联网公司都工作过的老司机就以平台架构视角和大家分享架构心得体会。一家之言，欢迎讨论。 本文首发于InfoQ垂直公众号「聊聊架构」，ID：archtime。 我对架构定义的理解 大概在7~8年前，我曾经有一个美国对口的架构师导师，他对我讲架构其实是发现利益相关者（stakeholder），然后解决他们的关注点（concerns），后来我读到一本书《软件系统架构:使用视点和视角与利益相关者合作》，里面提到的理念也是这样说： 系统架构的目标是解决利益相关者的关注点。 这是从那本书里头的一张截图，我之前公司分享架构定义常常用这张图， 架构是这样定义的： 每个系统都有一个架构 架构由架构元素以及相互之间的关系构成 系统是为了满足利益相关者（stakeholder）的需求而构建的 利益相关者都有自己的关注点（concerns） 架构由架构文档描述 架构文档描述了一系列的架构视角 每个视角都解决并且对应到利益相关者的关注点。 架构系统前，架构师的首要任务是尽最大可能找出所有利益相关者 ，业务方，产品经理，客户/用户，开发经理，工程师，项目经理，测试人员，运维人员，产品运营人员等等都有可能是利益相关者， 架构师要充分和利益相关者沟通，深入理解他们的关注点和痛点，并出架构解决这些关注点。 架构师常犯错误是漏掉重要的利益相关者

知乎的整个网站架构图如下： 知乎是国内很少的使用Python开发的一个网站，也很多值得我们学习的地方，从知乎让我们也可以了解到一些新的WEB技术。 一、Python框架 知乎目前使用的是 Tornado 框架。Tornado 全称Tornado Web Server，是一个用Python 语言写成的Web 服务器兼Web 应用框架，由 FriendFeed 公司在自己的网站FriendFeed 中使用，被facebook 收购以后框架以开源软件形式开放给大众。 参考链接： http://zh.wikipedia.org/wiki/Tornado 学习文档： http://www.tornadoweb.cn/documentation 二、数据库 目前知乎采用的是MySQL作为主要的存储，使用 SqlAlchemy 为ORM进行数据库的建模或者映射。 三、缓存技术 知乎使用 Redis 来进行缓存、队列、计数或者任务，使用 Redis-Py 为其连接客户端。 Redis参考链接： http://redis.readthedocs.org/en/latest/index.html Redis-Py参考链接： http://redis-py.readthedocs.org/en/latest/index.html 四、Javascript框架 知乎使用Google的 Closure

本人不才，分享一下系统架构方面的知识，个人经历：单体应用架构--->分布式架构--->微服务架构 基本概念 单体应用架构: 只有一个项目，且所有功能部署在一起 分布式架构: 一个应用拆分成不同的业务，部署在不同的服务器上；分散服务器压力； 微服务架构: 分布式架构的延伸，进一步解耦复杂业务，多个微服务可以进行组合，组合后可以构成一个相对复杂的业务系统，以满足业务需求；目的是分散业务能力； 核心要素 《大型网站技术架构》中提到5大要素 性能 可用性 伸缩性 扩展性 安全性 详情可参考《大型网站技术架构》这本书以及这篇文章 http://www.cnblogs.com/me115/p/3662421.html 理解误区 架构师就是吹牛？ “架构实际上解决的是人的问题，而概念是人认识这个世界的基础”-----引自资深架构师王概凯《架构漫谈》架构师是一个很宽泛的说法，目的是为了解决实际问题与业务瓶颈； 分布式与集群？ 一个是工作方式，一个是物理形态，分布式是指将不同的业务分布在不同的地方；而集群指的是将几台服务器集中在一起，实现同一业务；分布式中的每一个节点，都可以做集群，而集群并不一定就是分布式的； 个人小结 入行近两年，业务越写越顺，坑越踩越多，最近开接触架构相关知识，参加过几次线下活动； 职业升级路线：初级工程师--->中级工程师--->高级工程师--->资深专家--->架构师

汽车之家数据平台架构 互联网企业数据仓库构建是采用自下而上的方式，还是自上而下的方式？如果你是一个数据部门的架构师，你怎样去规划数据仓库呢？2015年中国数据库技术大会上，来自汽车之家用户智能组的高红锋为我们介绍了汽车之家平台架构。包括如何实现数据价值，数据价值的保障，实现数据价值的必经之路等。 详细解读 和小伙伴们一起来吐槽 来源： oschina 链接： https://my.oschina.net/u/856019/blog/406649

1. 前言## 看到了这个 http://www.oschina.net/question/926166_2137672 然后有人写了博客还分析设计了一下 http://my.oschina.net/u/926166/blog/522227 本人最近对架构设计较感兴趣，下面是我的设计，可以做到极大化性能和水平扩展，所有的性能issue都在网络IO。redis存储方面轻松支持同时上亿个订单。 2. 基于redis的详细设计## 使用一个高可用的时间序列发生器服务器。timeserver。 订单server产生了订单之后立即往redis的订单号服务器写一条记录，key为timeserver的nanosecond，存储类型为sorted set。把订单的详细信息写入另一个redis的详单服务器集群(用订单号hash写入)。 订单服务器有一个定时器线程，60s运行一次，时间到了发送一条消息（包含time server的当前nanosecond）给短信发送server。 短信发送server收到nanosecond的消息后，去redis订单号服务器取出所有小于该nanosecond的订单号，开启多个协程用订单号去redis详单服务器集群拿到详单数据，发送短信。 redis配置成高可用。订单业务server和短信server都是无状态的，可以横向水平扩展。 3. 性能估计数据量估计##

今天，数据库的操作越来越成为整个应用的性能瓶颈了，这点对于Web应用尤其明显。关于数据库的性能，这并不只是DBA才需要担心的事，而这更是我们 程序员 需要去关注的事情。当我们去设计数据库表结构，对操作数据库时（尤其是查表时的SQL语句），我们都需要注意数据操作的性能。这里，我们不会讲过多的SQL语句的优化，而只是针对MySQL这一Web应用最多的数据库。希望下面的这些优化技巧对你有用。 0. 为查询缓存优化你的查询 大多数的MySQL服务器都开启了查询缓存。这是提高性最有效的方法之一，而且这是被MySQL的数据库引擎处理的。当有很多相同的查询被执行了多次的时候，这些查询结果会被放到一个缓存中，这样，后续的相同的查询就不用操作表而直接访问缓存结果了。 这里最主要的问题是，对于程序员来说，这个事情是很容易被忽略的。因为，我们某些查询语句会让MySQL不使用缓存。请看下面的示例 // 查询缓存不开启 $r = mysql_query("SELECT username FROM user WHERE signup_date >= CURDATE()"); // 开启查询缓存 $today = date("Y-m-d"); $r = mysql_query("SELECT username FROM user WHERE signup_date >= '$today'");

前言 高并发经常会发生在有大活跃用户量，用户高聚集的业务场景中，如：秒杀活动，定时领取红包等。 为了让业务可以流畅的运行并且给用户一个好的交互体验，我们需要根据业务场景预估达到的并发量等因素，来设计适合自己业务场景的高并发处理方案。 在电商相关产品开发的这些年，我有幸的遇到了并发下的各种坑，这一路摸爬滚打过来有着不少的血泪史，这里进行的总结，作为自己的归档记录，同时分享给大家。 服务器架构 业务从发展的初期到逐渐成熟，服务器架构也是从相对单一到集群，再到分布式服务。 一个可以支持高并发的服务少不了好的服务器架构，需要有均衡负载，数据库需要主从集群，nosql缓存需要主从集群，静态文件需要上传cdn，这些都是能让业务程序流畅运行的强大后盾。 服务器这块多是需要运维人员来配合搭建，具体我就不多说了，点到为止。 大致需要用到的服务器架构如下： 服务器 均衡负载(如：nginx，阿里云SLB) 资源监控 分布式 数据库 主从分离，集群 DBA 表优化，索引优化，等 分布式 nosql redis 主从分离，集群 mongodb 主从分离，集群 memcache 主从分离，集群 cdn html css js image 并发测试 高并发相关的业务，需要进行并发的测试，通过大量的数据分析评估出整个架构可以支撑的并发量。 测试高并发可以使用第三方服务器或者自己测试服务器

一、架构 　　架构即软件架构， 是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。软件体系结构是构建计算机软件实践的基础，简单来说，软件架构是一个系统的草图，是一种设计方案，将客户的不同需求抽象成为抽象组件，各个组件之间的连接则明确和相对细致地描述组件之间的通讯。 　　在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。 二、框架 　　 框架即软件框架， 通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品。 　　框架的功能类似于基础设施，与具体的软件应用无关，是项目软件开发过程中提取特定领域软件的共性部分形成的体系结构，提供并实现最为基础的软件架构和体系。软件开发者通常依据特定的框架实现更为复杂的商业运用和业务逻辑。这样的软件应用可以在支持同一种框架的软件系统中运行。 　　简而言之，框架就是制定一套规范或者规则（思想），大家（程序员）在该规范或者规则（思想）下工作 ，不同领域的软件项目有着不同的框架类型。框架不是现成可用的应用系统。而是一个半成品，提供了诸多服务，开发人员进行二次开发，实现具体功能的应用系统。 三、设计模式 　 设计模式（ design pattern）是对软件设计中普遍存在（反复出现）的各种问题

聊聊尖叫娱乐的未来，尖叫娱乐注册登录官方指定站 PingCAP 成立五周年前夕 我还清楚记得，五年前的这个时候，当时还在豌豆荚，午后与刘奇和崔秋的闲聊关于未来数据库的想象，就像一粒种子一样，到了今天看起来也竟枝繁叶茂郁郁葱葱，有点感慨。按照惯例，五年是一个重要的节点，没有十年那么冗长，也没有一两年的短暂，是一个很好的回顾节点，就在此认真的回顾一下过去，展望一下未来。 五年前创业的出发点其实很朴素：做一个更好的分布式数据库。从学术的角度上看起来，并不是提出了什么惊天地泣鬼神的神奇算法，我们选择的 Shared-nothing 的架构其实在当时的业界也不是什么新鲜的事情了，但真正令我激动的是：我们要造的是一个真正能作为整个系统的 Single Source of Truth 的基础软件。这句话怎么理解呢？我在后边会好好聊聊。 数据是架构的中心 作为一个互联网行业的架构师，几乎是天天都在和各种类型的数据打交道，这么多年的经验，不同行业不同系统，从技术层面来说，抽象到最高，总结成一句话就是： 数据是架构的中心。 仔细想想，我们其实做的一切工作，都是围绕着数据。数据的产生，数据的存储，数据的消费，数据的流动……只不过是根据不同的需求，变化数据的形态和服务方式。计算机系的同学可能还记得老师说过的一句话：程序 = 算法 + 数据结构，我这里斗胆模仿一下这个句式：系统 = 业务逻辑 x 数据