架构师

Daniel Mohl是一名专业的软件工程师/架构师，他的兴趣包括理解各种复杂的编程语言、企业应用架构以及如何搭建业务与技术，他通晓F#、C#、CoffeeScript、JavaScript、Erlang、ASP.NET、MVC、WPF、WCF、Sliverlight、SQL Server等技术。有着多年的软件开发经验。 他经常会被一些有潜力和有前途的程序员问到：“我要怎么做才能成为一名架构师？”说实话，这已经是老生常谈的话题了，答案当然是视情况而定。不过他也根据自己的经验，给大家一些建议，并且提供一些资料，助你快速走上架构师这条道路。 下面是Daniel Mohl所提出的列表，供大家参考： 首先，你必须不断地寻求改善和提升自己。而提升自己的最好方法是阅读，下面有几本书，对我的软件架构技能的提升很大。推荐给大家： 软件架构师应该知道的97件事 企业应用架构模式 敏捷软件开发，原则，模式和实践 企业集成模式 JavaScript语言精髓 利用遗留代码有效地工作 领域驱动设计 企业架构策略 设计模式（四人帮） The Goal SOA设计模式 SOA Principles of Service Design 除了阅读，还有没有其他需要注意的、或者在平时需要关注的东西呢？ 每隔一两年学习一门新语言，F#是个不错的选择。 选择一个重点领域，但是尽可能对许多技术有个高层次的理解

摘要：本文作者王庆友，前 1号店首席架构师，先后就职于 ebay、腾讯、1号店、找钢网，精通电商业务，擅长复杂系统业务建模和架构分析，目前在中国 B2B 第一电商公司找钢网担任首席架构师，微信号Brucetwins，欢迎一起聊架构。 　　目前讨论架构实操（术）的文章较多，讨论架构理念（道）的较少，本文基于作者在大型电商系统架构方面的一些实践和思考，和大家聊聊架构理念性的东西，希望能够抛砖引玉，推进大家对架构的认识。 　　什么是道，什么是术？道是事物发展的本质规律，术是事物发展的具体途径。规律只有一个，途径很多，条条大路通罗马，罗马是道，大路是术。道为本，术为途，如果事先知道罗马在哪里，那么遍地是路，路路相通。架构也是如此，如果能领悟架构的本质，就不会拘泥于现有的实践和理论框框，而以最直接的方式解决问题，无招胜有招。本文的内容包括架构的本质、架构的服务对象、架构师能力模型 、架构境界等。 　　 架构的本质 　　任何系统，自然情况下，都是从有序到无序，这是有科学依据的， 按照热力学第二定律，自然界的一切自发过程都有方向性，一个孤立系统会由有序变为无序，即它的熵会不断增加，最终寂灭。但生物可以通过和外界交互，主动进行新陈代谢，制造 “负熵” 来保证自身有序，继续生存。 　　同样，一个软件系统随着功能越来越多，调用量急剧增长，整个系统逐渐碎片化，越来越无序，最终无法维护和扩展

架构的本质 原文作者王庆友，前 1号店首席架构师，先后就职于 ebay、腾讯、1号店、找钢网，精通电商业务，擅长复杂系统业务建模和架构分析，目前在中国 B2B 第一电商公司找钢网担任首席架构师，微信号Brucetwins。 原文连接 ，读后笔记，全部重新敲了一遍，有一定删减，侵删 目前讨论架构实操（术）的文章较多，而讨论架构理念（道）的较少，本文基于作者在大型电商系统架构方面的一些实践和思考，推进大家对架构的认识。 道与术，道是事物发展的本质规律，术是事物发展的具体途径。规律只有一个，途径很多，条条大道通罗马，如果事先知道罗马在哪，那么遍地是路。架构也是如此，如果能够领悟架构的本质，就不会拘泥于现有的实践和理论框框，而以最直接的方式解决问题，无招胜有招。本文的内容包括架构的本质、架构的服务对象、架构师能力模型、架构的境界。 架构的本质 一个软件系统随着功能越来越多，调用量急剧增长，整个系统逐渐碎片化，越来越无序，最终无法维护和扩展，所以系统在一段时间的野蛮生长后，也需要及时干预，避免越来越无序。 架构的本质就是对系统进行有序化重构，不断减少系统的“熵”（意为无效性，无序性，不可控等），使系统不断进化。 那架构师如何实现无序到有序的呢？ 基本的手段就是分和合，先把系统打散，然后重新组合。 分，则合理定位；合，则有机整体 分的过程是把系统拆分成各个子系统/模块/组件，拆的时候

互联网架构师学习笔记整理-完善中 一、并发编程 + ActiveMQ + 实战案例 并发编程基础篇 第一天 1、课程大纲简要介绍 2、线程基础概念、线程安全概念、多个线程多个锁概念 3、对象锁的同步和异步 4、脏读概念、脏读业务场景 5、Synchronized概念、Synchronized代码块、Synchronized其他细节 第二天 1、Volatile关键字概念、线程优化执行流程、内部原理讲解 2、Volatile关键字的非原子性 3、并发编程下的多线程间通信概念wait、notify，线程经典面试题讲解 4、模拟底层阻塞队列（queue）实现讲解 5、单例和多线程如何结合使用 并发编程中级篇 第三天 1、同步类容器讲解 2、并发类容器讲解 3、Concurrent集合类讲解与底层原理实现 4、CopyOnWrite集合类讲解与底层原理实现 5、各类并发Queue详细讲解 第四天 1、多线程设计模式之Future模式讲解与模拟实现 2、多线程设计模式之Master-Worker模式讲解与模拟实现 3、多线程设计模式之生产消费者模型讲解与模拟实现 并发编程高级篇 第五天 1、JDK多任务执行框架底层讲解与内部实现 2、默认线程池说明、底层代码讲解 3、自定义线程池说明、底层代码讲解 4、线程池拒绝策略讲解 5

性能调优系列前序文章索引： 必须掌握的性能调优 ：老兵哥结合个人经历解释了程序员往架构师方向发展时为什么要跨越性能调优这一关，以及介绍了从 X、Y、Z 三个维度优化性能的思路。 从 X 维度优化系统的性能 ：老兵哥分享了从 X 维度优化系统性能的思路，包括让客户端分计算存储任务、优化交互设计等，主要是作为引子拓宽我们性能调优的思路。 程序员在转型架构师的过程中需要建立流程化、结构化、系统化的思维方式，而性能调优是非常难得的契机，它既给了我们压力，也给了我们动力，跨越它就是突破自己的过程。 X 维度， 即业务维度，技术始终是服务业务的，任何技术问题的原点就是业务需求。在启动技术层面的性能优化之前，我们有必要先审视一下业务流程是否合理，交互设计上有没有可以优化的空间等。 Y 维度， 待业务维度优化完毕，接下来就是审视技术在实现当前业务流程或交互设计的全链路上有没有可优化的地方，即 HTTP 请求处理全流程，从浏览器到应用容器，再到 Spring、Hibernate、 数据库 等。 Z 维度 ，除了沿着 HTTP 请求的横向链路，我们还要审视支持应用系统的纵向技术栈，从上到下包括 JVM 、操作系统和硬件等，这是整套应用系统运行的环境，许多性能问题都跟运行环境存在关系。 Y 维度 ，就是从业务 HTTP 请求的横向处理流程来看，HTTP 请求会穿越网络、计算机、应用容器（Tomcat）

阿里P8架构师谈：如何设计淘宝亿级系统架构！ 优知学院 2018-09-20 18:31:30 类似淘宝这样的大型网站，需要涉及到如下架构设计技术 1.业务拆分 应用程序拆分，拆分后如何通讯、拆分步骤、拆分的原则等。 比如我以淘宝为例：根据业务属性进行垂直切分，划分为商品，订单系统、用户系统、购物车系统，支付系统，评论系统，客服系统等，系统拆分后会涉及到消息通讯机制，以及以下的集群部署。 2.应用集群部署（分布式部署，集群部署和负载均衡） 分布式部署：将业务拆分后的应用单独部署，应用直接通过类似Dubbo远程通信； 集群部署：电商网站的高可用要求，每个应用至少部署N台服务器进行集群部署； 负载均衡：是高可用系统必须的，一般应用通过负载均衡实现高可用，分布式服务通过内置的负载均衡实现高可用，关系型数据库通过主备方式实现高可用。 3.分布式中间件技术 分布式缓存：Redis为代表的，以及TFS、GFS、HDFS为代表的分布式文件存储等。 4.单点登录（分布式Session） 系统分割为多个子系统，独立部署后，不可避免的会遇到会话管理的问题。一般可采用Session同步，Cookies，分布式Session方式，大型网站一般采用分布式Session实现。 5.数据库集群（垂直拆分、读写分离，分库分表） 数据库的数据量过大之后，需要按照业务为单位进行数据库垂直拆分。淘宝为例，拆分为商品库

网站跨域的五种解决方式 1、什么是跨越？ 一个网页向另一个不同域名/不同协议/不同端口的网页请求资源，这就是跨域。 跨域原因产生：在当前域名请求网站中，默认不允许通过ajax请求发送其他域名。 2、为什么会产生跨域请求？ 因为浏览器使用了同源策略 3、什么是同源策略？ 同源策略是Netscape提出的一个著名的安全策略，现在所有支持JavaScript的浏览器都会使用这个策略。同源策略是浏览器最核心也最基本的安全功能，如果缺少同源策略，浏览器的正常功能可能受到影响。可以说web是构建在同源策略的基础之上的，浏览器只是针对同源策略的一种实现。 4、为什么浏览器要使用同源策略？ 是为了保证用户的信息安全，防止恶意网站窃取数据，如果网页之间不满足同源要求，将不能: 1、共享Cookie、LocalStorage、IndexDB 2、获取DOM 3、AJAX请求不能发送 同源策略的非绝对性： <script></script> <img/> <iframe/> <link/> <video/> <audio/> 等带有src属性的标签可以从不同的域加载和执行资源。其他插件的同源策略：flash、java applet、silverlight、googlegears等浏览器加载的第三方插件也有各自的同源策略，只是这些同源策略不属于浏览器原生的同源策略，如果有漏洞则可能被黑客利用

关于程序员和架构师的讨论很多，我想从不同的角度说下。 寻路 当我刚进入软件行业成为一名程序员时，我的理想就是成为一名架构师。架构师这个词的英文叫 Architect，原意是建筑师，因为软件行业参照借鉴了很多建筑行业的概念，所以就借用这个词。我是在学校读书时知道架构师这个名词的，当时很多软件方面的书都是翻译过来的，现在也不知道是谁最早把 Architect 翻译成架构师的了。总之从那时起，架构师这个名词对于我这个还刚准备走出校门的学生来说就特别高大遥远，自然当成了最初的一个职业目标。 可惜，我进入第一家公司后，这是一个家民营 IT 服务企业，我发现居然没有架构师这个职位。我所在的一个几十人团队里，本科刚毕业的是助理工程师，硕士刚毕业的是初级工程师，然后是中级，高级工程师。再往上就变成了项目经理、这个团队就是一个项目经理，下面有几个高工，然后一堆初级和助理工程师。让我颇为失望的是，我当时明显觉得未来我的职业发展目标并不是当时团队项目经理所处的方向。不过一想我离架构师这个目标还早，当时估计最快也要十年吧，先把程序写熟再说，我也不太可能在这里干十年，以后换个就好了。 实际，一年后我就换了个公司，入职后又失望了，发现还是没有架构师这个职位。不仅没有架构师职位，连工程师都不分初、中、高级了，全是软件工程师，再上面是组长、科长、部长，然后就是总经理。科长、部长这类职位是国营性质的

小伙伴们，新年好！ 感谢大家对「 IT老兵哥 」原创文章的支持顶赞，❤️❤️❤️！把有价值的知识或经验分享给更多人，在分享中提升个人价值，这是我写作、分享的初衷和动力，在新的一年里我会更加努力，也希望能够继续获得各位小伙伴的支持！坚持原创不易，如果文章有价值，千万要记得手动点个「 👍 」哦！ 祝大家新年在家庭、事业和生活上都有新的进步！关注「 IT老兵哥 」，赋能程序人生，我们一起加油干！⛽️⛽️⛽️ 年前我们一起聊了 程序员为什么要懂架构 、 架构是什么 和 架构都有哪些类型 这三个话题，今天我们来看看架构师是怎样开展工作的，他/她需要对接上下游哪些角色，以什么作为工作输入，最终要对外输出什么产物。这些内容既有助于我们跟架构岗同事更好的协作，也可以作为是否往架构转型的参考，接下来我们一起揭开架构师的神秘面纱吧！ 1. 架构设计的输入是什么？ 软件系统最终要构建成什么样，这是由项目干系人的各种要求决定的。通常，我们将这些要求归集在产品需求文档之中，这份产品需求就是架构设计的输入。我们可以将这些需求划分为： 功能需求：完成某项业务需要的功能操作，例如：共享单车客户端软件需要支持单车定位、扫码解锁等。 质量需求：每项功能操作要达到什么样的质量要求，例如：易用性、可靠性、安全性、性能等等。 商业需求：软件系统需要以什么样的成本、迭代速度推向市场，如何提升产品的市场竞争力等等。 2.

开学第一课我们观看了《梦想改造家》，在这个案例中，冯家的老房子沿街而建，总体呈三角形形状，从某个角度看，老屋单薄得像是纸片。“纸片屋”共有25平方米，对三口之家来说，人均绝对值并不算太低，但被称为最稳固的三角形却带来了一堆麻烦，处处的尖角无可利用，造成了极多的空间浪费，经过设计师王平仲的改造，纸片屋变空中花园。我们在惊叹于设计师的设计外，有没有想过一个建筑设计师的工作流程类似于一个软件架构师的工作流程。 软件架构师并不是普通的程序员，这是软件行业中一种新兴职业，工作职责是在一个软件项目开发过程中，将客户的需求转换为规范的开发计划及文本，并制定这个项目的总体架构，指导整个开发团队完成这个计划。主导系统全局分析设计和实施、负责软件构架和关键技术决策的人员。 架构师首先要进行需求分析，就像王平仲第一时间去拜访了委托人一样，得到真实可靠的需求。有人认为架构师是在需求规格说明书完成后介入的，只对最终的需求审核和确认，提出需求不清和不完整的部分。但也有人认为架构师要从项目最开始的阶段就参与进来。我个人比较倾向于第二种观点。由于分析人员在与客户交流时，往往不会深入挖掘需求，有很多隐藏的需求客户自己可能意识不到，而架构师则可以依靠敏感的软件嗅觉发现这些需求，另外，分析人员往往脱离开发团队，盲目接受客户需求，而架构师能够清楚把握现有的研发团队能做什么，不能做什么，提前预知风险，降低项目失败的机率