㈠ Java架构师需要具备哪些能力
具备 8 年以上软件行业工作经验；
具备 4 年以上 C/S 或 B/S 体系结构软件产品开发及架构和设计经验；
具备 3 年以上的代码编写工作经验
具备丰富的大中型开发项目的总体规划、方案设计及技术队伍管理经验
对相关的技术标准有深刻的认识，对软件工程标准规范有良好的把握
对 .Net/JAVA 技术及整个解决方案有深刻的理解及熟练的应用，并且精通WebService/J2EE 架构和设计模式，并在此基础上设计产品框架
具有面向对象分析、设计、开发能力(OOA、OOD、OOP)，精通 UML 和 ROSE，熟练使用 Rational Rose、PowerDesigner 等工具进行设计开发；
Java架构师要求是很高的，除了要精通JAVA方面知识以外，还要掌握计算机所有软件方面，以及部分硬件方面的知识。
程序设计方面：JAVA、JAVA Application、JAVA EE(例如：EJB、RMI、JMS、WebService)、开源、设计模式、JavaScript、C/C++、.NET方面、VBA 。
数据库方面：SQL、ORACLE、MySQL、索引、分区、分片、主从、存储过程 。
网络及浏览器：TCP/IP协议、HTTP协议、FTP、HTML、XML、浏览器 。
操作系统：Linux系统、Shell/批处理、文件系统(各种)、SSH 。
中间件：Tomcat、Apache、Nginx、lighthttpd、JBoss、WebSphere、Weblogic、IIS。
技术和思想：各种算法、搜索、缓存、多线程、UML、OO、SOA、AOP、REST、存储、云计算等。
业务方面：论坛、博客、社交、电子商务、应用程序等 。
其它方面：计算机基础知识、计算机硬件方面 。
个人软素质：经验、问题分析、大局观、心态等 。
企业需求：
㈡ 什么叫缓存命中率
其中很多人谈到了缓存命中率的问题，应用缓存的命中率取决于很多的因素：
1、应用场景
是OLTP还是OLAP应用，即使是OLTP，也要看访问的频度，一个极少被访问到的缓存等于没有什么效果。一般来说，互联网网站是非常适合缓存应用的场景。
2、缓存的粒度
毫无疑问，缓存的粒度越小，命中率就越高，对象缓存是目前缓存粒度最小的，因此被命中的几率更高。举个例子来说吧：你访问当前这个页面，浏览帖子，那么对于ORM来说，需要发送n条SQL，取各自帖子user的对象。很显然，如果这个user在其他帖子里面也跟贴了，那么在访问那个帖子的时候，就可以直接从缓存里面取这个user对象了。
3、架构的设计
架构的设计对于缓存命中率也有至关重要的影响。例如你应该如何去尽量避免缓存失效的问题，如何尽量提供频繁访问数据的缓存问题，这些都是考验架构师水平的地方。再举个例子来说，对于论坛，需要记录每个topic的浏览次数，所以每次有人访问这个topic，那么topic表就要update一次，这意味着什么呢？对于topic的对象缓存是无效的，每次访问都要更新缓存。那么可以想一些办法，例如增加一个中间变量记录点击次数，每累计一定的点击，才更新一次数据库，从而减低缓存失效的频率。
4、缓存的容量和缓存的有效期
缓存太小，造成频繁的LRU，也会降低命中率，缓存的有效期太短也会造成缓存命中率下降。
所以缓存命中率问题不能一概而论，一定说命中率很低或者命中率很高。但是如果你对于缓存的掌握很精通，有意识的去调整应用的架构，去分解缓存的粒度，总是会带来很高的命中率的。
这里我可以举一个实际的案例，JavaEye2.0网站在使用对象缓存之前，通过MySQL的监控工具进行观察，在连续24小时的平均每秒发送SQL条数超过了200条，在使用对象缓存之后，连续24小时的平均每秒发送SQL条数下降到了120条左右，几乎下降了一半。
考虑到很多SQL都是分页语句，关联查询，条件查询，集合操作，都是不能被缓存的SQL，而真正能够被缓存的SQL只有根据主键查询对象和对象关联对象的查询。所以真正能够被缓存的SQL估计最多占所有SQL的60%。所以换算下来，应用缓存的命中率之高，已经相当惊人了。
不过这里要提醒的一点，有将近一半的SQL都被缓存，不意味着性能可以提升一倍。这是因为能够被缓存的都是按照主键查询单条记录的SQL，这些SQL本身即使发送到数据库，对数据库造成的压力也没有想象的那么大。真正对数据库造成庞大压力的正是那些没有索引的大表查询，和造成了全表扫描的关联查询，这些一旦涉及到全表扫描的查询，才是性能的真正杀手。当然了，不管怎么说，通过使用对象缓存，是毫无疑问可以大幅度降低数据库的负载压力的，有效提升web应用的性能的。
关于这一点，我再给出一组数据来加深大家的印象，通过使用操作系统网络工具进行统计：
JavaEye网站web server的端口每秒数据流量是2MB；
JavaEye网站的MySQL数据库端口的每秒数据流量是1.2MB；
而网站的memcached的端口每秒的数据流量高达5MB
㈢ 如何成为一个架构师
1、技术能力
技术能力，不用置疑肯定是最重要的。技术能力弱的架构不是一个好架构。所以，你需要知道所有主流技术的基本原理、应用场景，及快速解决问题的能力。所以，架构师必须要有见识，所需知识面肯定是要不断拓展的。
你需要清楚在什么样的场景用什么样的技术比较合适，并知道可能存在什么样的风险。来了需求，你脑袋是空的，不知道用什么技术这是最可怕的。
2、架构能力
这个可以表现为抽象能力、整体规划能力、及设计能力。你需要照在业务的角度进行系统分解、技术选型、架构搭建，以及规范制定。架构出来了至少可以满足最近的发展，或者可以很方便对现有架构进行扩容。
3、沟通能力
作为一个优秀的架构师，你需要清楚的知道客户的需求，需要不断和需求人员进行沟通，以达到客户真正的目的。不论是不是架构师，任何一个职场人，提高自己的沟通表达能力无疑是不可或缺的。
系统架构师的主要功能包括：
1、系统架构师是软件项目的总体设计师，是软件组织新产品的开发与集成、新技术体系的构建者。
2、系统架构师是在技术上对所有重要事情做出决定的人（系统架构师在整个软件开发过程中都起着重要作用，并随着开发进程的推进而其职责或关注点不断地变化）。
3、需求阶段，软件架构师负责理解和管理非功能性系统需求，比如软件的可维护性、性能、复用性、可靠性、有效性和可测试性等。
4、设计阶段，架构师负责对整个软件架构、关键构件、接口的设计。协助系统分析师完成《系统概要设计说明书》。
5、编码阶段，架构师则成为程序员的顾问，并且经常性地要举行一些技术研讨会、技术培训班等。
6、测试及实施阶段，随着软件开始测试、集成和交付，集成和测试支持将成为软件架构师的工作重点。
㈣ 架构师具体需要学些什么
但如果要做一名网站架构师的话，还需要学些什么呢？仅个人看法一般的，如果你是很有经验的phper，有过大中型网站开发经验，基本上就能担任架构师因为php本身就面向架构的一般正规公司，除了技术总监外，架构师应是核心人物也有人认为架构师分硬件部署架构师和软件架构师专业开发中，软件架构师一般是面向对象建模和数据库建模人员。所以，掌握uml可能是必要的。数据库知识也是必要的。但数据知识也可以由dba兼任。硬件架构师多指部署。服务器集群构建。一般对系统掌握要好，要了解常用的服务器系统和软件。比如：linux,负载均衡，数据库集群。分布缓存。
一是能安装管理，还要会用。其本上以上两点中任何一个，要做到都不容易。网站架构师：
所好的事一般的网站不是那么复杂的系统。所以，知识和经验很重要。所以，一般的phper都身兼数责，足够用。架构师的实践原则：创建面向对象，高性能，易部署，易维护，可扩展，高内聚，低耦合，可移植的系统也有人强调可用性。
㈤ 架构师退休以后干什么
架构师退休以后干：做分析师
架构，感觉好厉害的样子，从名称上来说，好像是设计根骨，设计底层，设计最核心的东西的人。
整个系统只有一个WEB，Spring MVC+Spring+Hibernate搞定一切，开始做需求分析，实际上就是设计表结构而已，剩下的就是查查查，改改改，删删删。
缓存这玩意儿，在很早之前学习各种基础课程的时候，了解过一些，一级缓存，二级缓存什么的。
㈥ 互联网架构师必须具备的技能
架构师是公司的“金领”，有着非常高的收入，很少需要考虑生存的问题，从而有更多的精力思考关键技术问题，形成“强者愈强”的良性循环。部分优秀的开发人员在工作了一定时间后，就要开始考虑自己的未来到底向哪个方向发展。如果开发人员的沟通能力强过技术能力，在补充一定的项目管理知识后，可以向技术管理的方向转型。如果其对技术一直很感兴趣，而沟通能力也不弱，则可以试着进一步加强技术修养，以期向架构师的方向发展，最终“修成正果”。
那么，到底什么是架构师呢？所谓的架构师，应该是一个技术企业的最高技术决策者。他主要负责公司软件产品或软件项目的技术路线与技术框架的制订。好的架构师都是善良的独裁的人，具有很强的技术、良好的写作能力、良好的口头表达能力，能够在各个层次进行沟通。从开发人员到架构师的成长应该是阶梯式的，一般来讲开发人员在刚刚开始工作时只能开发简单的独立软件模块，慢慢的随着经验的增长，他开始接触一些相互之间有信息传递的模块，而后来，他会发现自己接到的开发任务已经不是一个独立的单体，这些任务由一些专门的软件部分组成，可能包含数据库，工作流引擎，消息服务等等各种功能模块，可能分布在不同的服务器上，所有的部分协同起来，完成软件功能。而这时候，体系结构的好坏将直接决定了系统的性能和可扩展性，而就在这时候，这名优秀的开发人员也开始思考架构师应该思考的问题了，或者说，他向成长为架构师的道路迈出了一大步。
什么是架构师最具价值的技能呢？就是要了解不同的知识，做一个“杂家”或者说“博学家”。当然，如果你的数据库技术非常棒，或者你在工作流引擎方面具有不可超越的专家知识，那也是很不错的。好的架构师有好多都是从专家成长过来的。但是，这不是架构师应该做的事情，架构师应该做的是了解所有的东西，既了解技术的宏观面，又了解技术的细节。真正的架构师不仅仅要了解软件，也要了解硬件，在关键的部位使用合适的硬件来取代软件，可以成倍甚至成百倍的提高整个系统的效率。下面我将会以互联网行业对的架构师的要求为例，向大家讲解作为架构师应该具备的知识。
互联网行业是当前最激动人心的行业之一，很多的创新都来自于这个行业，而每一个大型的网站如google，yahoo，myspace等都需要解决一个非常复杂的问题，就是网站的分布式向外扩展(scale out)的问题。解决这个问题，需要最优秀的架构师对业务进行剖析，利用软硬件将网站进行重构，甚至根据业务研发相应的分布式技术，解决网站复杂的分布式计算的问题。如果你想在这个行业中成为一名架构师的话，需要至少掌握网络知识，硬件，软件，网站优化等方方面面的知识：
1.网络知识
当前的软件已经绝对不是那种仅仅跑在一台单机上的孤立应用了。不仅仅是在互联网行业，任何一个行业的软件，都要求其具有网络功能。因此，网络知识是架构师必备的知识。我们所说的网络知识，不仅仅包括tcp/ip，http等互联网行业常用的软件协议，也包括网络规划，甚至更具体的说，根据网站应用所处的地理环境进行网络规划。比如人们常说：“这世界上最远的距离不是生与死的距离，而是电信到网通的距离”(笑)如果应用是建立在中国的，就要考虑电信用户和网通用户访问网站的速度应该都比较快才可以。这时候的解决方案可能有多种，比如采用cdn(content delivery network内容分发网络)使得网站的内容发布到离用户最近的服务器，又可以采用把服务器放在一些所谓的双线机房中，甚至将几种方案结合起来使用。这些都统统归到网络知识中。做为公司的架构师，要对这些知识都有所了解，才有助于在遇到问题时找到最佳答案。
2.硬件知识
了解硬件的极限，是架构师的基本功。我见过一些人，他们的眼中软件硬件都是没有极限的，需要资源就申请，系统性能下降了就买更高级的设备。然而，硬件的性能有很大一部分取决于i/o设备。而这些i/o设备依靠的都是机械物理运动，这种运动是有极限的。因此当资源访问量增大到一定的程度时，这种物理运动将成为瓶颈。比如说，在开发网站的过程中，记录访客的状态是一件很重要的事情，一般来说可以使用httpsession来记录。而httpsession的存储问题将是一个很大的挑战，尤其是多机共享session时，将httpsession存成文件并通过多机共享或网络备份的`方式来解决分布式的问题是常用的方案，然而，架构师必须考虑到这种方案是有i/o极限限制的，很难扩展到超过一定规模的大型网络。同时，架构师应该了解目前最近的硬件发展是否对软件系统会造成一定的影响，比如在多核的条件下是否对软件编程有新的要求，是否会对运行在虚拟机和非虚拟机上的程序有影响等等。
3.软件知识
软件知识所包含的范围就更加广泛了。对于互联网行业来讲，架构师要了解操作系统，数据库，应用服务器等各方面的知识。比如说，如果网站使用的操作系统是linux，就要了解这个linux版本的性能与局限性，比如说最多可以存放的单个文件为多大。有的数据库的数据是以单个文件来存放的，虽然我们很
少见到数据库中的数据多到不能再放入一条记录的情况，但是作为架构师，请时刻注意，这种可能性是有的。而且如果你有幸在一家高速成长的互联网企业中，而你所负责的应用又没有经过优化的话，可能你会很快见到这种现象。这种现象的发生可能是由于操作系统不支持大文件的原因，也可能是数据库不支持大文件。不论如何，架构师应该在这种现象发生之前就把一切都准备好。对数据库中表的拆分是架构师应该遇到的另外一个困难。一般来说增加应用服务器比较简单而增加数据库服务器则是比较复杂的问题，如果一个站点由多个数据库支持，架构师需要考虑如何在保证数据一致的情况下，让多个数据库分担压力。有些解决方案是将数据库的读写分开，使得大多数的查询sql不经过核心数据库，而只是访问数据库的副本，但事实上，这种方式也只能维护规模不大的网站。对于大型的网站来说，把业务分散到不同的数据库中，只共享必要的数据，才是合理的提高网站扩展性的解决方案。
4.其他知识
作为系统架构师，可能还需要对分布式系统，负载均衡，网络安全，数据监控等等各方面都有所了解。不仅仅是了解理论知识，也要对相关的产品和业界进展有一定的认识。比如说做负载均衡最好的产品是那种。目前最常用的备份策略是什么，有什么缺点。如何使用缓存，如何做好日志分析等等。
刚刚谈到的是架构师需要掌握的知识，然而，冰冻三尺非一日之寒。这个过程需要我们慢慢的积累。如果你已经进入到公司进行软件开发，请时刻关注你所开发软件的性能与可扩展性，而不仅仅局限在功能上，时刻想着任何一个简单的问题：我开发的模块如果放在多人并发的环境下会怎样，慢慢的就会有所心得。如果你还是一个在校学生，不要想着自己离架构师这个职位还很遥远。要知道，成为架构师的修炼之路是很长的，甚至可以说是终身的，因此早点进入学习状态，不断修炼自己。在学校期间学好离散数学，数据结构，操作系统，编译原理，体系结构，数据库原理等关键课程，并积极寻找机会到外面实习，增长自己的工作经验。如果有机会去到一些技术主导的公司中工作，就一定不要放弃这种机会，慢慢就会成长起来。最重要的，你会养成关注技术，勤于思考的好习惯。当有一天你发现自己对任何技术难题都可以一眼看到其本质，并能够将其分解为一个个可轻松解决的模块，你会由衷的感觉到知识给你带来的快乐，或许那一天，你已经是一个架构师了。
拓展：架构师必须具备的能力
1、软件架构的定义：
软件架构(Software Architecture)也称之为软件体系结构，它是一组有关如下要素的重要决策：软件系统的组织，构成系统的结构化元素，接口和它们相互协作的行为的选择，结构化元素和行为元素组合成粒度更大的子系统方式的选择，以及指导这一组织(元素及其接口、协作和组合方式)的架构风格的选择。换句话说，软件架构实际上是对系统整体结构设计的刻划，系统架构师是做全局的、整体的把握工作。架构的组成与决策是架构设计的两个基本概念。架构=>蓝图+规则+解决方案。
软件架构是一个认识事物的过程：原型、发现、改进、再发现、再改进，这是软件开发的必由螺旋。
2、架构师成长路线图：
系统架构师已经不仅仅是技术精湛的技术专家，他需要与业务团队紧密合作，并且精通市场、业务与管理。从上升趋势来说，可以有三个层面的路线图：第一个层面，要关注系统思考。在这个层面，重要的不仅仅是掌握设计的知识点，而是更重视分析能力、创新思维能力的提升，需要更广阔的思路，这方面的空间相当非常大。这是第一层面的能力基础。第二个层面，要关注总结和指导，思维空间要转向群体。如何把已有的经验总结出来，并让这种智力资产真正发挥作用?成为架构师上升第二层面的能力基础。第三个层面，要提升自身的全面修养。我们必须引发自己思维方式的变革，要培养组织力、领导力、创新力以及拥有激情，这是架构师上升第三层面的能力基础。
要看到自身的弱点，思路要宽，多思考
架构师并不是一个普通的技术人员，他对设计站的角度更高，需要的知识和能力结构更复杂，他需要具有其他人所没有的思想、眼光和感知世界的方法，必须突破已有的思维模式和行为模式，突破长期束缚自己的思维瓶颈，才可能达到自己从未达到过的高度。
架构师要养成每项工作都记录并分析的好习惯，以形成更扎实的工作风格。在每个项目完成都需要进行总结。
3、架构师要保持自己的竞争力：
架构师必须关注今天的IT技术、商业模式变革以及由此引发的软件产业变革的重大趋势，勤于思考并迎接新的挑战。一个人最核心的竞争优势是学习能力。架构师作为技术层面资深的一群，为了保持竞争力需要注意以下几个问题：
(1)、保持激情：关键是信念。激情源自于信念，有了信念才会主动挑战自我，迎接挑战才会有激情，有了激情工作才会更有意思。
(2)、创新思考：在工作中多尝试一些新方法，是维持自我能力的重要手段。
(3)、逆向思维：逆向思维指的是使用与正常思路相反的思维方式去分析同一个问题，使思路多样化。逆向思维能够帮助人们冲破传统思维的束缚，克服惯性思维方式。从反方向考虑问题往往会取得出人意料的结果。
4、架构师要关注软件的新趋势：
目前传统软件危机暴露出的问题还未真正解决，新的挑战却已摆在眼前。在人们不断思考面临的挑战以及对策中，形成了一些新的趋势，包括：
(1)、软件质量以服务质量形式展现，对质量的投资可获得更高的投资回报。
(2)、软件过程扩展到用户，希望更多的用户深入参与到软件全生命周期。
(3)、功能至上远远不够，用户体验得到空前重视。
(4)、系统集成模式面临变革，软件、服务、终端、IT基础设施将形成更紧密的价值体系。
(5)、研发要更多关注非功能性需求，如安全性质量、性能、可靠性、可扩充性、可伸缩性、可用性等，从而不断提高软件的价值。知识就是力量==>信息就是力量。
架构并不完全是概要设计。概要设计还是停留在图纸上，而架构必须证明这个技术路线可行，并且能够证明大多数质量风险已经得到了解决。
5、所谓设计就是解决问题的过程：
软件设计是一种思维活动，设计的魅力在于破解难题，通过直面问题的挑战，以及对相应解决方案的仔细推敲，才可能设计出真正有灵性的产品。
(1)、设计不具普遍性：软件设计很少具有普通性，不同的目标需要不同的设计来支持。
(2)、做出权衡：所谓软件设计，本质上就是在质量、成本、时间以及其它各种因素之间做出权衡。
(3)、记录设计的理由(设计文档)。多关注各种方面的架构设计。
㈦ 华为技术架构师分享：高并发场景下缓存处理的一些思路
在实际的开发当中，我们经常需要进行磁盘数据的读取和搜索，因此经常会有出现从数据库读取数据的场景出现。但是当数据访问量次数增大的时候，过多的磁盘读取可能会最终成为整个系统的性能瓶颈，甚至是压垮整个数据库，导致系统卡死等严重问题。
常规的应用系统中，我们通常会在需要的时候对数据库进行查找，因此系统的大致结构如下所示：
1.缓存和数据库之间数据一致性问题
常用于缓存处理的机制我总结为了以下几种：
首先来简单说说Cache aside的这种方式：
Cache Aside模式
这种模式处理缓存通常都是先从数据库缓存查询，如果缓存没有命中则从数据库中进行查找。
这里面会发生的三种情况如下：
缓存命中：
当查询的时候发现缓存存在，那么直接从缓存中提取。
缓存失效：
当缓存没有数据的时候，则从database里面读取源数据，再加入到cache里面去。
缓存更新：
当有新的写操作去修改database里面的数据时，需要在写操作完成之后，让cache里面对应的数据失效。
关于这种模式下依然会存在缺陷。比如，一个是读操作，但是没有命中缓存，然后就到数据库中取数据，此时来了一个写操作，写完数据库后，让缓存失效，然后，之前的那个读操作再把老的数据放进去，所以，会造成脏数据。
Facebook的大牛们也曾经就缓存处理这个问题发表过相关的论文，链接如下:
分布式环境中要想完全的保证数据一致性是一件极为困难的事情，我们只能够尽可能的减低这种数据不一致性问题产生的情况。
Read Through模式
Read Through模式是指应用程序始终从缓存中请求数据。 如果缓存没有数据，则它负责使用底层提供程序插件从数据库中检索数据。 检索数据后，缓存会自行更新并将数据返回给调用应用程序。使用Read Through 有一个好处。
我们总是使用key从缓存中检索数据, 调用的应用程序不知道数据库， 由存储方来负责自己的缓存处理，这使代码更具可读性， 代码更清晰。但是这也有相应的缺陷，开发人员需要给编写相关的程序插件，增加了开发的难度性。
Write Through模式
Write Through模式和Read Through模式类似，当数据发生更新的时候，先去Cache里面进行更新，如果命中了，则先更新缓存再由Cache方来更新database。如果没有命中的话，就直接更新Cache里面的数据。
2.缓存穿透问题
在高并发的场景中，缓存穿透是一个经常都会遇到的问题。
什么是缓存穿透？
大量的请求在缓存中没有查询到指定的数据，因此需要从数据库中进行查询，造成缓存穿透。
会造成什么后果？
大量的请求短时间内涌入到database中进行查询会增加database的压力，最终导致database无法承载客户单请求的压力，出现宕机卡死等现象。
常用的解决方案通常有以下几类：
1.空值缓存
在某些特定的业务场景中，对于数据的查询可能会是空的，没有实际的存在，并且这类数据信息在短时间进行多次的反复查询也不会有变化，那么整个过程中，多次的请求数据库操作会显得有些多余。
不妨可以将这些空值（没有查询结果的数据）对应的key存储在缓存中，那么第二次查找的时候就不需要再次请求到database那么麻烦，只需要通过内存查询即可。这样的做法能够大大减少对于database的访问压力。
2.布隆过滤器
通常对于database里面的数据的key值可以预先存储在布隆过滤器里面去，然后先在布隆过滤器里面进行过滤，如果发现布隆过滤器中没有的话，就再去redis里面进行查询，如果redis中也没有数据的话，再去database查询。这样可以避免不存在的数据信息也去往存储库中进行查询情况。
什么是缓存雪崩？
当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力。
如何避免缓存雪崩问题？
1.使用加锁队列来应付这种问题。当有多个请求涌入的时候，当缓存失效的时候加入一把分布式锁，只允许抢锁成功的请求去库里面读取数据然后将其存入缓存中，再释放锁，让后续的读请求从缓存中取数据。但是这种做法有一定的弊端，过多的读请求线程堵塞，将机器内存占满，依然没有能够从根本上解决问题。
2.在并发场景发生前，先手动触发请求，将缓存都存储起来，以减少后期请求对database的第一次查询的压力。数据过期时间设置尽量分散开来，不要让数据出现同一时间段出现缓存过期的情况。
3.从缓存可用性的角度来思考，避免缓存出现单点故障的问题，可以结合使用 主从+哨兵的模式来搭建缓存架构，但是这种模式搭建的缓存架构有个弊端，就是无法进行缓存分片，存储缓存的数据量有限制，因此可以升级为Redis Cluster架构来进行优化处理。（需要结合企业实际的经济实力，毕竟Redis Cluster的搭建需要更多的机器）
4.Ehcache本地缓存 + Hystrix限流&降级,避免MySQL被打死。
使用 Ehcache本地缓存的目的也是考虑在 Redis Cluster 完全不可用的时候，Ehcache本地缓存还能够支撑一阵。
使用 Hystrix进行限流 & 降级 ，比如一秒来了5000个请求，我们可以设置假设只能有一秒 2000个请求能通过这个组件，那么其他剩余的 3000 请求就会走限流逻辑。
然后去调用我们自己开发的降级组件（降级），比如设置的一些默认值呀之类的。以此来保护最后的 MySQL 不会被大量的请求给打死。
㈧ 架构中的业务能力和技术能力
谈架构我们谈什么，如果单单谈技术是不行的，架构师起到承上启下的作用，上负责与客户与业务涉众沟通，下负责让团队理解需求和如何通过技术实现需求。架构师的语言包括架构图，同时我们还要谈论 业务能力 和 技术能力 。
业务能力是我们从业务需求、系统类别、行业背景分析出的，主要是按业务范围或业务领域进行一定的划分，比如说合同系统，那么合同审批、合同签署、合同存档等就是业务能力。
技术能力是从我们选择的技术、平台、基础结构中体现出来的。如AWS S3的对象存储能力，Lambda的无服务器计算能力，DynamoDB的NoSQL数据存储能力，ElasticSearch的搜索能力，又如ElastiCache的缓存能力和CloudFront的CDN能力。
架构师所做的架构设计实际上就是一个函数f(x)，x是业务能力，所得f(x)是从业务能力映射出的技术能力。技术能力的全景图就是技术架构图，同时我们也可以通过技术债列表反应出我们所需要的技术能力以及技术能力的风险。
架构师跟客户及业务团队、涉众通过业务能力以“业务语言”进行沟通，比如“合同审批需要支持多级可打回的自定义审批流程”、“合同签署需要支持电子合同签署”、“合同归档要实现合同扫描件及电子合同的保存”等等。这里我们不提及要使用的技术、产品、服务、品牌、平台和基础设施，原因是客户和涉众并不能理解你的这些技术词汇。
架构师跟应用开发和运维团队以“技术语言”进行沟通，比如“合同审批采用开源，支持多节点并行审批并可退回前节点的自定义工作流产品”、“合同签署采用Web界面和签名采样控件进行电子签署”、“合同归档需要满足ISOxxxx的合同记录管理系统”等等，这里我们要提起技术、产品、服务、品牌、平台和基础设施，帮助开发和运维团队理解在未来的时间里他们需要做哪些准备和工作，项目经理需要明白还需要何种能力的人力或其他工作资源。
通过业务语言和技术语言的双向沟通，架构师起到承上启下帮助技术团队理解业务需求，通过技术满足客户和涉众所提需求的目的。
㈨ 为什么说缓存相当于一个数据库
临时存储的地方，其实说白了，一个txt文本也能相当一个数据库。
什么是数据库，就是可以存储信息的地方。
当然它不一定具有
增删改查的内置方法
但是你不能不承认。它存了东西，就可以被定义成数据库
所以，缓存相当数据库
可以理解。
㈩ 一个五年架构师为什么基本年薪酬可以达到50万
架构师，我想很多人都知道，其实该职位头衔在最早的IT领域是没有的，它是近些年来由互联网的发展所引发的需求，因为现阶段的数据量及高并发的活跃好动，引起了不少传统的技术人员的力不从心，企业愈发关注到了系统架构的重要性，所以不同行业开始招募架构技术人员，架构师就诞生了。
架构设计的条件
以下三个条件不适合做架构设计
对架构不感兴趣，但又迫于需求；
入IT行业，年限小于4年的；
主观能动性弱，又安于现状的；
架构设计的优势
更好的梳理业务的结构体系；
更好的拓展、维护及性能优化；
更好的适应企业业务灵活的推进；
更好的适应大数据的冲洗和应对；
更好的稳定性、低成本及快速迭代；
架构设计时候需要注意的地方
架构设计需要注意的地方，不是怎么把架构搭建起来，而是必须根据业务需求，严格分析，实现该需求需要什么技术会更好及更长远发展的考虑；
另外，构建好的架构虽然可以运行，但是性能需要跟起来，否则架构设计会适得其反，增加不必要的工作量，那么下面就详细介绍下架构设计的策略。
平台的需求
客户需求
在线购物、在线支付或货到付款；
购买商品后，客户可以与客服沟通；
购买商品过程，物流的管理及跟踪；
收取到商品后，商品、物流评价打分；
客户的需求为最高，也代表了企业的核心需求，当然，企业需求还包括其它很多非功能性需求，具体请查看需求梳理部分。
平台的业务架构
根据业务的需求进行子系统模块划分，可以划分为商品子系统、购物子系统、支付子系统、物流子系统、客服子系统、评论子系统；而非核心需求可拆分出客服子系统、评论子系统及接口子系统。另外，根据各个子系统的核心等级，可拆分出核心子系统和非核心子系统，前者包括商品子系统、购物子系统、支付子系统及物流子系统；后者，则包括评论子系统、客服子系统及接口子系统。需要注意的是一般大型电商平台的物流系统是单独分离出来的系统（入库、出库、库存管理、配送管理及货品管理），而这里划分为子系统的主要目的是为演示核心架构，本架构中物流子系统一般作为对接和管理独立子系统的对接模块哦。
1、业务拆分目的
为了解决各个模块子系统间的耦合、维护及拓展性；
方便单独部署子系统，避免集中部署导致一个出问题，全部不能用；
分配专门的团队，负责具体的子系统，最大化工作效率安排；
应对大数据，高压力时，保护核心子系统正常使用；
2、业务的架构图
在上面的业务架构图中，将核心和非核心业务进行拆分，同时每个系统都要独立部署实现，做到大数据量压下，各个系统独立运作，提高可用性，必要时可以暂停掉非核心系统的资源开销，保证核心业务正常为用户服务。
平台的技术架构
在上面业务架构图基础上，我们需要一个技术架构的演变过程，一切只为满足用户的体验和支撑为前提，所以技术架构的搭建不是一蹴而就的，而是随着业务的不断衍变，系统的架构会逐渐完善更新，以实现应对业务数据量的冲击。
1、基本的架构设计
记得很早的时候，很多中小企业所采用的架构设计十分简单，基本使用一台服务器来满足一切需求部署，比如：一台服务器同时用作应用部署、数据库存储以及图片存储等，不料的是待用户数据达到50万以上，系统出现很多性能问题，尽管对数据库和程序做个各种性能优化，结果仍无明显改善，架构如下：
后来，IT程序猿发现图片的读写严重影响了系统性能，并将图片单独存放在独立服务器中，并且在架构中引入了Cache中间件，比如：Memcache，这种做法是可取的，而且比原来性能提高了1-2个性能级别，架构设计如下：
2、初级的架构设计
前几年，一般的电商网站的做法是选用三台服务器，一台部署应用，一台部署数据库，一台部署NFS文件系统，做到将各个规模庞大并耗用性能的部分剥离到不同服务器设备，再配备必要的缓存中间件，基本可以满足近1000万的数据量，具体的架构图如下：
但是，目前主流使用的网站架构已经不同，大多采用集群的方式来实现负载均衡和高可用性，架构可以是下面的样子：
注意：
如果涉及到多台网站服务器的话，就会存在Session如何同步的问题，一般也是最为常用的做法，就是使用Cache中间件来存储和管理Session信息。
3、优化的架构设计
这里为解决高并发，高可用的大型电商网站的架构设计方案，主要采用了分布式、集群、负载均衡、反向代理、消息队列及多级缓存技术。该架构设计方案，是现今比较流程的大型电商网站采用的架构模式，比如：淘宝、京东等，也许会有细微不同的地方，但大同小异哦！具体的架构图方案如下：
平台架构的总结
这里主要总结的是优化架构，架构按层次结构罗列组织，共分为四层，层次分工明确，高拓展，低耦合，负载均衡、集群、分布式及缓存等技术的使用，架构如下：
好了，电商平台的架构设计就介绍到这里，本篇主要是介绍架构设计的思路及应用的核心技术，供在架构设计的同学参考借鉴哦！有想了解更多的可以关注我