本文归纳自赵杰辉（阿里云中间件产品总监）在阿里云栖大会上的分享，大家各取所需。
什么是互联网架构？
把传统的 IT 架构，从一个物理的专用硬件设备搬到云上，这不是互联网架构。开了一个公众号，亦或做一个 O2O 项目，也不能算互联网架构。
互联网架构有三个特征：
- 第一是敏捷性。
首先要想清楚客户为什么需要互联网架构重构他的 IT 系统？这里举一个例子，中石化的供应链的平台，今年是跟阿里合作开发的。中石化体量太大，若按传统的 IT 架构去做，从发标到最后上线，至少需要一年时间。可基于阿里巴巴的互联网架构，从第一次接触到最后上线，只用了 90 天时间，到运行四个月已经达成 70 多亿的交易额。
在供应链平台上线之后，两三个月时间又把中石化的会员卡系统上线，随后又是物流系统上线。所以互联网架构的第一个特征就是非常创新敏捷。
- 第二是扩展性。
整个互联网架构的计算能力，随着机器的增加，其性能和能力都是可以线性扩展的。
这里其实有两个含义，第一是在类似于 “双 11” 这种高并发场景下，它可以线性扩展；第二是当你要搭建一个覆盖全国或者全球的大平台，综合原来所有的 IT 系统架构依旧发现资源不足时，它可以线性扩展。这就像，基于以前的传统 IT 系统，我们的社保不能各个省联通成一个大平台，税务也是这个道理。
- 第三个是共享和开放性。
在基于传统 IT 的信息化建设中，做一个 ERP 系统或者几百个其他的系统，里面是有非常多的重复开发，这就是能力的不共享。
而阿里的互联网架构下，整个集团用户的管理，其实是作为一个服务共享给所有 BU 的。当做完第一个系统后，用户管理的能力便沉淀下来，这种共享能力被逐渐成为一个业务的共享层之后，再做一个新的系统或者业务时，只需要做一个差异化的业务逻辑就可以。
这就是内部共享，当积累更多，就可以选择开放和运营起来，共享给合作伙伴，这就是生态。
云计算是另一类运营商
电信运营商是运营着通信能力，云计算的公司是运营着计算能力，所以在互联网作为一种基础设施的前提下，云计算其实是另一类运营商。
站在企业的角度，最后每一个企业都会变成它核心能力的运营商。例如一个传统的制造企业，他具有设计能力、品牌能力、用户管理能力等，如果通过互联网架构，把这些核心的能力抽象成一个一个的微服务，通过运营，这些能力可以开放给所有的子业务单元，可以开放给下一个供应链和各个合作伙伴。那么企业就变成了其核心能力的运营商。
阿里巴巴的逻辑是，不仅可以去共享基础设施的云化，还可以实现业务能力的云化。这里就需要大规模的分布式数据库，包括整个服务化的理念等。
如何去快速复制阿里巴巴已经沉淀下来的互联网架构？
先看一下基本框架：最底层是企业级互联网架构，往上到中间这一层就是共享服务层，顶层就是能力开放平台。
这里有一个挑战，当原来的用户管理能力，是在不同的 IT 系统中以不同的形式存在，比如说用户的信息可能在 A 系统中是一种数据形式，B 系统又是另外一种形式，双方孤岛式的存在，在抽象成一个共同的用户管理中心能力之后，需要支撑的就不只是一个业务流了，要求必须是能力可线性扩展。
再来，把一个专用硬件上跑的独立的烟囱式系统，拆成一个横向的、平台化的、分布式的系统之后。有一个问题：这个系统虽然很好，当它越来越大的时候，运维怎么去治理，那么就要有数据化的运营。
说白了就两件事情，一个是在整个系统中做任何一次点击，整个服务集群里面的链路要被跟踪下来。再一个就是结合流计算的技术，能够实时的分析这些数据。真正的互联网架构，还要做到当服务对象感知出问题之前，系统已经知道自己出问题了，并切换掉。
也就是说，第一个挑战是分布式系统的平台和运维之间的矛盾出现后，必须要靠数据化和实时计算的方式去处理。
接下来会有第二个问题，小的垂直式系统被封入一个大的平台之后，有些调用会变成跨网络的调用，那么一定会遇到一个系统性的瓶颈。这时候，必须从架构上提升它的性能，也就是 MQ 起到的作用。此外，在分布式的服务框架等把计算层面的瓶颈打开之后，数据库会出现线性的扩展，数据数访问的链接等等也需要加机器让它线性扩展。
等这些都做完，整个的企业级互联网架构也就建起来。服务的中心可以涵盖供应链、销售、物流、客户管理，甚至把整个企业的能力全部服务化。
这里有一个思考，整个的企业各种 IT 流程、各种数据流，全部被统一到一个平台上去，有什么好处？
我们讲工业 4.0 的概念，最核心的就是从智能的销售，智能的客户管理，智能的物流，智能的供应链，最后整个的信息流打通，实现类似于 C2B 的逻辑。其实企业级互联网架构能够扩展到一个平台上的时候，工业 4.0 就可以落地了。
现在对于互联网的理解，都是工具和应用很多，但是底层架构讲的很少。例如，“双 11” 其实不光是买东西的盛宴，某种意义上是对一个企业商业基础设施的测试。阿里的架构也是经过七次 “双 11” 的锤炼沉淀和优化下来的东西。
这个架构有几个原则，最核心的一个原则，就是把企业的核心能力孵化出来。之后不应该看到企业是独立的一个个系统，而是面向全流程的自动化。
到这里，就涉及三个关键产品：
第一个是 EDAS 产品，这是一个分布式应用框架。超过 99%的阿里内部的应用，都已经在类似于这个上面去跑。该产品很好的封装了后台，所以对于程序员的要求是非常低的。例如，北京国税跟阿里的合作项目中，就只派了十几个应届生在这个平台的基础上，三个月内搭建起了系统。
第二是 DRDS 产品，也是大概超过 90%的应用基本上每天都在使用它，每天的调用量，分布式的数据查询也都在千亿次的级别。
再就是 MQ 这个产品。
这里再分享一个跟芒果 TV 的合作案例。在构建上，大概 40 天时间就完成了整个系统，更关键的一点是他们创新了播放的模式。尤其在粉丝互动时，整个网络的访问量会非常大，系统非常繁忙，在节目开始的时候发现系统能力不足了，只要再加机器上去就行了。充分体现了能力能够线性扩展，让所有的事情都会变的很平静。
总体来说，一个好的产品它有两个特征，第一个特征就是它能解决别人以前很难解决的矛盾。第二，当所有人用这个产品的时候，内心是非常淡定和平静的，不需要去做很多他不懂的事情。
文/36氪 徐宁
·氧分子网（http://www.yangfenzi.com）延伸阅读：
目前采用的应该是fat-tree架构。
具体的连接方式：
1. 20-40台服务器，通过AOC或铜缆连接到TOR
2. TOR通过光纤连接到群交换机。一个cluster的群交换机数量估计是4个，一个群的机架数我估计在100个左右。
3. 群交换机( cluster switch)，连接到核心交换机／路由器，再连接到广域网。
今天参加了一个论坛，EB这公司提了一个车用软件的架构，就是利用hypervisor使用一个nx多核系统跑多个系统，专门负责复杂逻辑的计算，减少单个小控制器的负荷成本，可以这样总体上可以costdown，且模块化更清晰(推测)的方案。
车用软件架构变迁简述:
1. 80-90年代使用单个ECU控制车辆
2. 现在的多控制器通过总线交互
3. 单个控制器按照功能分为io模块(实时部分)，domain control模块(非实时部分，且多个io模块可共用)，通过以太网相连
天下大势，分久必合合久必分，大家觉得
1. 互联网架构的变迁趋势是否真会影响到汽车行业？
2. 行业饼通过这种模式被重新划分，会产生出更多的标准模块制造商，也会产生新的行业需求(系统集成服务供应商)，对于这种架构，是否会受到传统行业巨头(博世大陆电装)的抵制？
目前大多数车用ECU基础软件架构还是OSEK/VDX，正在朝AUTOSAR架构方向发展。AUTOSAR是多数主流主机厂和零部件厂对今后车用软件架构发展方向的共识，其核心思想就是统一车用软件平台，达到应用软件复用的目的。理论上应该不会再推其他架构，比如你说的EB的多核系统（EB本身就是做AUTOSAR的）。
目前汽车上还是采用以CAN总线为骨干网的分布式系统，未来几年内最有可能替代CAN的可能是CANFD（CAN的升级版）。汽车上越来越多使用以太网是一个发展趋势，但无论从成本、实时性来说，以太网还取代不了CAN。以太网目前主要用在ECU的诊断、标定和软件刷新上。
题主说的网络架构我不太了解，至少目前来说不太可能实现。一个ECU上跑多核多系统本身就增加了系统的复杂性，而且汽车ECU讲究的是可靠、安全，不需要太复杂，但必须可靠、可预测。如果你这个ECU故障了需要更换的话，也可能增加了车主的维修成本。
嵌入式领域换个单片机重新改代码,底层驱动和开发环境就折腾死人还会导致不可预估的风险,你和我说要换架构…没极大的成本和需求驱动谁会去做…都是现在用下来没问题,只要不是成本能省下来特别多,就继续凑合着用,因为研发也是要钱的…从需求上来说,汽车领域里可以预见的比较复杂的逻辑运算也就一个自动驾驶了,但是也并没有到必须更改架构的地步.而且用一个微控制器来大包大揽的做法,安全性必然不如分布式控制器.
“互联网”是个被媒体说烂的词。在大量吹比、鸡汤的浸泡下，就连很多软件从业人员也搞不清这张网，到底是个什么“网”。
我这里不想纠结于互联网的定义，我姑且将题中的互联网等同于“用户多，访问频繁”的网站来聊聊吧。而且我只说Java的，别的不懂。
网站要给人看，所以首先要有一个好用的前端框架。比如市面上很常见的模版引擎（ freemarker ）+html（5）+jquery-xxx组合。
UI后头需要业务支撑。这里我可以很负责任地说：很多由Java编写的互联网项目，绝大部分也还是（SrpingMVC | Struts2）+（Hibernate | Mybatis）+Spring这个套路。
一般的项目，数据库该用什么用什么（其实还是Mysql居多，穷逼么）。 但是业务上来之后，可能关系型的这种方案会成为瓶颈，所以现在基于k-v的DB产品也是遍地开花，诸如MongoDB等。另外还需要针对一些关键点架设缓存、监控等。具体产品不表。
由于单台应用服务器的处理能力有限，需要做服务拆分。另外就算服务拆分了，单台服务器的负载也不足以支撑系统中某些核心服务的稳定运行。这时候又轮到集群出场了。机器和人一样，多了就不好管。各种各样的服务需要调度，协议一致，版本一致。。。。这其中又涉及到很多技术和协议，鄙人了解不深，不想只贴个名词装逼。
有过互联网经验的都知道，用户的一个信息都是宝贵的，浏览记录、购买记录。。。这些记录看似渺小，但是一旦有了用户量以及时间的支撑，便会成为一个庞然大物（tb级，甚至是pb级）。单台服务器不足以计算（主要是计算、分析）、存储这些东西，这有需要一个分布式生态。对的，生态：分布式文件存储、计算等。
上面说的这些，可能不会全部出现在一个项目中，但是万变不离其宗。我是按照应用的各个技术层次谈的，不是具体产品。
诸如淘宝网的网站架构是什么？这种蠢问题实在是让人无语。能答的不屑答，不能答的还拼命问，呵呵。
最大的不同在于 SNA (Share Nothing Architecture) 与 Session共享这两种架构的不同。传统的J2EE是非常重视Session共享，并基于此开发了很多应用。而互联网因为并发大，将Session保存在Memcache等中。
无状态是互联网架构的核心和根本。如果还有其他的话，那就是在CAP中，基本放弃对强一致性的追求，重视分区和可用性。比如MySQL的主从就不是一个强一致性的架构。
所有的操作系统的选择最终还是在于人的选择，相对来说linux的操作简单很多，而且国内大学里面的计算机课程都是讲redhad，这直接导致大部分人更熟悉linux，另外还有一点就是linux的驱动支持和一些新特性比较前卫,这也是大多技术宅比较喜欢的，相对沉稳的bsd就没有那么好命，再说一点就是如果你用习惯了linux你会和别人谈bsd么
非百度员工猜测的几个关键字：C，PHP，集群，缓存，队列，数据异构
这几年的经验：
业务层透明耦合松->硬件层横向可扩展
数据层冷热切分好->缓存层队列可推拉
做好这四点，95%的Web应用就没啥问题了。
中小型公司，产品导向小团队，比较合理的人员结构：
一个高端且洁癖的稳重架构师控制技术路线（面向对个小团队）
一个中端而耐心的资深工程师指导业务实现（面向单个小团队）
几个低端但积极的年轻编码者快速响应需求（注重小版本迭代）
一个优秀程序员的月薪就可以买一台X86服务器，不到万不得已尽量不考虑用人解决问题。
但没有一个高端的架构师（百度最不缺）坐镇，堆服务器（百度更不缺）的结果就是系统莫名奇妙的问题束手无策，且迭代速度越来越慢。
这玩意估计没人能答全细节
事实上
这些公司里
基本上一个大部门会有自己的独立的开发流程和架构
不过也不外乎这些玩意
编码规范
CSS
JS
HTML
小文件开发引入规范
AMD
CMD
自定义等
项目目录结构规范
lib、或组件开发（使用）规范
codereview
版本库使用及方式
git
svn
主干开发、分支上线
或相反等
上线方式
是否强制经过codereview
前端独立上线
前后端一起上线
运维上线等
辅助工具
代码扫描类
语法、规范符合与否扫描
注释扫描提取文档
代码修正类
CSS 补全
JS 修正语法树、补全
IDE
代码合并打包类
图片压缩类
版本控制器类
通过框架（vue，angular，kissy）组织，把html、css、js写成不像html（mustache，dot，jade）、css（less，sass，compass，stylus）、js（babel，coffee）
用模块工具或框架（webpack，broswerify，seajs，kissy）组织各种模块化（cmd，amd，kmd）、组件化
再用工具（grunt，gulp）打包解析压缩合并成html、css和js，最后版本控制（git，svn，cvs）
发布到静态资源平台（cdn），后端提供接口前端渲染或是后端（有时候权限也在前端那儿）将前端html文件套成后端语言模板发布上线。
总而言之，离不开“三化”——模块化，组件化，工程化
目前分为手机端和PC端两种开发流程
手机端：
前后端完全分离，采用Vue.js作为开发框架，NPM作为包管理，Less组织样式，Webpack作为模块加载工具，Gulp作为打包工具，反正是前端使用怎么方便怎么来，各种新奇的玩具都可以用上，后端只需要提供数据接口，开发完成后直接打包把静态资源丢到CDN上，这样的模式开发起来最舒服。
PC端：
因为考虑到SEO问题，所以不能采用前后端完全分离的方式。考虑到后台是Java开发，所以不能引进nodejs作为中间层渲染（我强烈要求引进，毕竟前端把控渲染层能够做更多的优化以及开发更为舒适，但是nodejs开发不好招啊，还有运维没有node经验，我一个人扛不来啊，所以只能作罢～），那么采用velocity模版作为渲染层，前端产出页面，然后自个按照velocity模版进行占位符填充，然后再丢给后端进行数据渲染，没有问题就可以将页面返回给前端，编译打包等等流程也全部由前端处理，前后端相安无事，前端改改样式，写写js，完全不要依赖后台。
建立之初最重要的目的是业务验证。因此选择团队最熟悉的技术栈较靠谱，比较容易实现快速迭代，及时调整业务。
如果出于技术性、成本性的考量， 需要在其他的平台作抉择，选用比较成熟的技术框架来搭建可以规避很多的风险。
业务架构的复用度通常不高，大多是核心信息结构比较匹配。但随着系统不断的运营调整，差异化会不可避免的发生。因此在业务框架的选用上，工作量评估不能过于乐观。尽量选择自由度较高的结构。
回到楼主的问题，如果当前重点是质量和稳定性，那么全体迁移到PHP后，依旧无法保证（纵使是基于已有框架二次开发），毕竟学习成本、现有的能力都是无法一蹴而就。所以从技术的角度，我并不建议切换。
可以考虑对当前的框架做一个排查，看问题主要出现在基础架构还是业务逻辑。如果是基础架构的问题， 那么换用一个更加合适的Web框架可能会解决很多安全性、稳定性的问题。如果是业务逻辑层，尝试在领域模型、数据访问、接口定义三块找优化的空间。
分析下领导的想法和java优点,应该是停留二十世纪初的,或者某些从学校出来的学生从老师那里听到的,java会比较慢,性能堪忧,但是随着目前JKD 版本的提升,java的性能并不会很低效,同样的代码在一定时间后执行效率并不会比C语言差,何况是php了,在成规模的项目上php的效率不见得会比java高效,稳定性 方面 都有自己的gc .而安全性 不知道从何谈起,一个是解释型语言,一个是编译型 领导在考虑哪方面的安全性?
PHP的使用率在10年封顶后,一直保持在下降的趋势,虽然java的使用率一直受到其他web开发软件的占领,但是还是保持第一的宝座(数据是各大编程语言的使用量,Java应考虑包括手机端的使用)
总的来说,考虑使用那种语言是因为哪种语言更适合当前的环境,例如 预期项目规模,侧重点等等,而不应该考虑因为 coder的代码质量不行而去换语言…
语言躺枪啊..
再有,java代码写不好,PHP代码就可以写好?
——————–
在小项目中 功能点在只有页面的时候 PHP确实会比Java开发速度快,但是在项目升级或维护上会很快遇到瓶颈
通常来说，web后端更接近产品和业务，开发中可能需要跟前端、移动端、产品做很多沟通，接口的设计、具体feature的实现等等可能是更关注的点。
Web后端工程师最基础的要求是掌握一门后端开发语言，比如Go/PHP/Ruby/Python/Java等。实际工作中可能会使用一些具体的开发框架，比如Beego/ThinkPHP/RoR/Django等。数据库比如MySQL、Restful API的设计、HTTP相关知识等等也是基础。实际工作中可能还需要知道Redis, RabbitMQ,zooKeeper等等。
但是并不是所有互联网公司都有做「基础架构」的，很多中小型公司追求的是「full stack」, web后端工程师可能需要熟悉整个后端的架构甚至是运维。
得益于开源，现在有大量的傻瓜式工具链，可以帮助一个后端工程师快速搭出一个可用的系统来。
基础架构工程师则可能更关注一些基础组件，为后端工程师提供「服务」，比如RPC、负载均衡、消息队列、Mongodb/Redis的集群服务、网络框架、存储中间件等等。
二者技术栈差不多，并没有谁强谁弱之分，只是分工不同。（虽然我们会习惯性地认为基础架构就是牛，WEB开发很低端）。
后端工程师追求的目标，都是开发出「高性能」「高并发」「高可用」的系统来。
一个优秀的架构师，则是二者的合集。
Web后端工程师在开发上会偏重业务，而后端基础架构会偏重于通用型更强的工作，比如消息系统，任务调度系统等。两者的交叉点在于一个应用，一个开发。虽说web后端偏业务，但是如果对自己所用的基础架构开发出来的东西理解不深，也不能很好的应用。而基础架构如果不了解业务，那通用组件也没办法很好的适配各种场景。
技术栈两者相差不大，但对深度上基础架构会要求更多一些。当然，这只是通常情况。因为两者都对高并发，高性能、可复用性有要求，所以如果想要成为大牛级别的人物，都需要加深知识深度。web后端应该具体项目有较大关系吧。例如一个网站的后台的业务逻辑，数据流向之类的。
基础架构可能更多是开发一些公共组件。例如猫厂有一个高性能网络产品开发平台NetFrame，在用户态实现了网络协议栈，减少了网络通信时的内存拷贝，其后的有些安全产品基于这个平台二次开发，这种应该就属于基础架构工程师的活。
两者的相同之处都要求高并发、高可用，毕竟这是一个数据爆炸的时代。