架构师

加QQ:976789649@qq.com 来源： https://www.cnblogs.com/houniaodetiankong/p/11685194.html

我在做技术面试官的时候，面试对象大多数是初级开发和高级开发，偶尔也会面试架构师。我发现，IT人的工资固然和相关技术的使用年限有关，但如果候选人的技能无法跨越到更高层次的话，他们的收入也就会停留在当前级别，哪怕工资年限再多，也无法提升工资水平。 比如，我就面试过不少工作了5,6年的程序员，他们的技能也就停留在增删改查阶段，那么只能领到初级程序员的工资。更可悲的时，在面试过程中我发现他们甚至不知道上升的途径和方式，这样的话，可能当他们有10年经验时，或许还只是初级程序员。 对此本文将围绕着初级程序员，高级程序员和架构师这三个职位，说明下这些级别的技能瓶颈，并给出若干突破瓶颈的建议。 1 初级程序员的技能瓶颈与收入瓶颈 哪怕是非相关专业，从培训班出来的程序员，要找个工作也不难，更何况是计算机相关专业出身的学生。 在一般的公司里，对初级程序员的要求大多也是会增删改查，熟悉基本的业务，而且不少公司不会让他们干更高级的活。所以我在面试过程中，不少3年以内的初级程序员的水平和一些有5年经验的人差不多，这就进入了初级程序员的收入瓶颈。 比如Java方面，他们仅仅会用技能，比如集合，多线程，数据库等，也会在Spring框架下干活，SQL方面，仅会写基本的SQL语句，或许还会使用简单的索引等技能。但如果我问及底层代码，他们知道得很少，问及Spring等框架知识，他们只会告诉我如何配置

对工作多年的程序员而言，日后的职业发展无非是专精技术，转型管理，晋升架构师三种选择。成为一名优秀的架构师，是大多数技术人的追求。 想要做架构，空有一身技术是远远不够的，知识的深度和广度，会决定一个架构师的架构能力。而这些知识，从你踏入 IT 行业那一刻起，甚至更早就应该开始储备了。 我见过很多人，做了 7、8 年程序员，仍然停留在「码农」的阶段，平时工作节奏太快，很难有机会系统学习架构，也没人教，只能闷头敲代码，越来越被动。 而一旦你拥有「架构思维」，胸中自有大局观，对职业发展、职场晋升都会起到巨大的作用： 提升自己在组织内部的话语权，获得领导的赏识，客户的青睐； 快速掌握新知识，避免陷入频繁加班的恶性循环，获得更多发展机会； 透过问题看本质，了解代码之下更深层次的机制，不仅能快速完成方案，且条理清晰，重点突出； 制定符合用户需求且可扩展的商业计划，从而牢牢地控制企业生命线； 所以，无论你是否已经是团队里的架构师，对任何一位程序员来说，具备架构思维都会成为让你脱颖而出的关键。 但据我在工作中的观察，很多人对「架构」的理解，还停留在产品经理出需求，架构师依据产品设计给出实现，也就是所谓的架构设计方案这一阶段。 在我看来，这其实是个误解。架构关乎整个工程，以及实现它的人，又因团队的能力而异。 同时，架构也关乎用户需求，作为架构师，我们不仅要知道当前的用户需求是什么

Swoole 和我们传统的 PHP 开发差别是有的，需要理解的概念也是有的。使用目前一些基于 Swoole 的框架开发的话，从开发习惯上和传统的TP 框架相差不多。根据官方介绍它是一个底层通信框架,最大的优势在于： 常驻内存，避免重复加载带来的性能损耗，提升海量性能 协程异步，提高对 I/O 密集型场景并发处理能力（如：微信开发、支付、登录等） 方便地开发 Http、WebSocket、TCP、UDP 等应用，可以与硬件通信 PHP 高性能微服务架构成为现实 那么很多人学习swoole都遇到了很多困难，那么我将在这里分享一套PHP架构师路线路以及教程，主要针对1到5年及以上的PHP开发人员，里面的技术包涵了PHP高并发、分布式、微服务、框架内核、高性能等技术，这些也是目前中大型互联网企业比较常用的技术，那么来详细看看。 一： 常见模式与框架 学习PHP技术体系，设计模式，流行的框架 常见的设计模式，编码必备 Laravel、ThinkPHP开发必不可少的最新框架 YII、Symfony4.1核心源码剖析 二： 微服务架构与 性能优化 业务体系越来越复杂，Swoole协程编程，PHP并发编程、MySQL底层优化是架构升级的必经之路，PHP性能优化和微服务相关的技术有哪些呢？ Tars分布式RPC框架 Swoft微服务框架 服务器性能优化 算法与数据结构 三： 工程化与 分布式架构

Soft skills are always hard than hard skills. 软技能比硬技能难。 老板听说最近流行“微服务”，问架构师咱们的系统要不要来一套？老板又听说最近流行“中台系统”，问架构师咱们要不要搞起来？其实，这些问题不用老板问，关注技术发展趋势的架构师每当听到新的技术或解决方案，都会暗中思忖是否应用到系统中。然而，用或不用，总不能凭感觉吧。此时，如果你能灵活运用康威定律，那么做出的判断将更加完美。 康威定律 康威定律是马尔文·康威1967提出的：“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗的来讲：产品必然是其（人员）组织沟通结构的缩影。 跨部门沟通是非常难的，系统各个模块的接口也反映了它们之间的信息流动和合作方式。 康威定律可谓软件架构设计中的第一定律，起初只是在杂志上的发表，后经过《人月神话》这本软件界圣经的引用，并命名为康威定律（Conway’s law），因此得以推广。 只通过简单的描述可能无法理解康威定律的精髓所在，原文中康威定律可总结为四个定律： 第一定律 组织沟通方式会通过系统设计表达出来。 第二定律 时间再多一件事情也不可能做的完美，但总有时间做完一件事情。 第三定律 线型系统和线型组织架构间有潜在的异质同态特性。 第四定律 大的系统组织总是比小系统更倾向于分解。 第一定律 Communication dictates

对于一个架构师，除了更加优秀的代码能力和 trouble shooting 能力外，需要构建当前技术领域的知识体系，需要有体系化的思维能力，需要对技术所服务的业务要有非常深入的了解。 体系化的思维能力，来源于两个方面。 一方面是在日常工作中，对每一个接口设计，每一个逻辑，每一个模块，子系统的拆分和组织方式，每一个需求的技术方案，每一个系统的顶层设计，都要反复思考和推敲，不断的复盘。 另一方面，需要大量广泛的学习行业内相似系统的架构设计，这其实就是开天眼，只是技术相对来说，行业内的交流更加频繁，淘宝、美团、百度、 Google 、 Facebook 、 Amazon 等各个公司介绍系统架构的论文和 PPT 铺天盖地，需要带着问题持续学习。 除了技术领域本身外，架构师需要非常了解业务上是如何使用我们的系统的，否则非常容易 over design ，陷入技术的自嗨中，这也是为什么我说 Amazon Dynamo 论文里讲的 Vector Clock 是个 over design 的原因。 另一方面，很多时候技术上绕不过去的坎，可能非常复杂的实现，往往只需要上层业务稍微变通一下，就完全可以绕过去，这也是为什么我说 GFS 论文里，多个 Writer 同时 Append 同一个文件是个根本没用的设计（实际上 Google 内部也把这个功能去掉了）。

从8月26到10月7日，一个多月的时间，把这本书看完，并摘录一些重要的内容。 基本上自己是先看一遍，然后将觉得应该多看几遍的地方写进博客。 很明显，自己需要掌握的很多，所以才有这么多篇。 收获颇多，将原文的内容理解，并敲一遍摘录，比光是看要吸收的多一点。后面需要不断地利用空闲时间翻阅。 书中不仅谈技术，还谈人生价值观。 认识到，架构师是什么样的人？主要的工作是什么？具体每项工作的关注点和解决思路？ 书中关于架构原理的是第一篇和第二篇。阅读之后，对高性能、高可用、伸缩性、可扩展性、安全会有个清晰的认知。 第三篇讲架构案例的，我没有做过多摘录，只是读了一遍，并在书中做了笔记。 最后是将架构师这个职业的，有关于职场、如何领导，做了一些阐述，让我对架构师这个岗位有更加感性的认识。 也让成为一个什么样的架构师更清晰。 来源： https://www.cnblogs.com/wozixiaoyao/p/11637750.html

架构的本质是管理复杂性，抽象、分层、分治和演化思维是架构师征服复杂性的四种根本性武器。 抽象、分层、分治和演化掌握的深度和灵活应用的水平，直接决定架构师所能解决问题域的复杂性和规模大小，是区分普通应用型架构师和平台型/系统型架构师的一个分水岭。 寻找最重要事情的20%，集中精力把它们完成，尤其是领导人心中要有一个不断更新不断权衡的重要事列表，然后用人所长，把重要的事安排给擅长他的人并与之达成共识有效的推进。 一方面要有序推进自己及团队重要工作的进展，一方面要预判未来可能发生的事。如果你团队经常会有领导安排下来的很急很重要的事要做，说明你对团队所负责业务的现实缺少全面的了解，对未来的问题及其重要性预判不够，和上面领导沟通汇报的不够，对市场可能的变化洞察太少。 认识自己、找到并坚持执行重要事情的能力也是一个人的核心竞争力，培养并提高它的一个有效方法是，坚持去做列出自己最重要的事，过后不断反思自己思考行为不足，然后持续迭代优化。 一般人总喜欢从自己的角度看事情，好一点的会从对方的角度看事情，而要真正的了解全貌看清事物的本质，还要从第三方、环境、时代背景的视觉看问题。平时工作、生活中有意识的提醒自己多运用“我、你、他”的视角看问题，渐渐的你会变的更智慧，更容易发现事物的本质。 来源： https://www.cnblogs.com/doit8791/p/11605782.html

场景 系统架构设计师考试，属于全国计算机技术与软件专业技术资格考试（简称计算机软件资格考试）中的一个高级考试。 系统架构设计师考试，考试不设学历与资历条件，不论年龄和专业，考生可根据自己的技术水平，选择合适的级别合适的资格，但一次考试只能报考一种资格。 实现 高级系统架构设计师2009年下半年上午试题 高级系统架构设计师2009年下半年下午试题Ⅰ 高级系统架构设计师2009年下半年下午试题Ⅱ 高级系统架构设计师2010年下半年上午试题 高级系统架构设计师2010年下半年下午试题Ⅰ 高级系统架构设计师2010年下半年下午试题Ⅱ 高级系统架构设计师2011年下半年上午试题 高级系统架构设计师2011年下半年下午试题Ⅰ 高级系统架构设计师2011年下半年下午试题Ⅱ 高级系统架构设计师2012年下半年上午试题 高级系统架构设计师2012年下半年下午试题Ⅰ 高级系统架构设计师2012年下半年下午试题Ⅱ 高级系统架构设计师2013年下半年上午试题 高级系统架构设计师2013年下半年下午试题Ⅰ 高级系统架构设计师2013年下半年下午试题Ⅱ 高级系统架构设计师2014年下半年上午试题 高级系统架构设计师2014年下半年下午试题Ⅰ 高级系统架构设计师2014年下半年下午试题Ⅱ 高级系统架构设计师2015年下半年下午试题Ⅰ 高级系统架构设计师2015年下半年下午试题Ⅱ

1.jvm类加载机制 2.JVM在搜索类的时候，又是如何判定两个class是相同的呢？ JVM在判定两个class是否相同时，不仅要判断两个类名是否相同，而且要判断是否由同一个类加载器实例加载的。只有两者同时满足的情况下，JVM才认为这两个class是相同的。 3.诊断Java中的内存泄露 https://cloud.tencent.com/developer/article/1342372 工具使用 https://blog.csdn.net/sinat_33760891/article/details/82425621 SESSION, COOKIE区别 session数据放在服务器上，cookie则放在客户浏览器上。cookie不太安全，因为可以分析出本地cookie，并进行cookie欺骗，考虑安全应使用session。session会在一定时间内保存在服务器上，当访问增多时，会比较占用服务器的性能，考虑减轻服务器压力则应该使用cookie。单个cookie保持的数据不超过4k，很多浏览器都限制要给站点最多保存20个cookie。 应用服务器集群的session管理-多台服务器共享session问题 把sessionId（还有用户信息，比如user_id）保存到数据库即可（最终选择redis,因为会比较快！），验证时不再从当前服务器获取sessionId