php大型应用如何采用分布式架构_php如何实现分布式

大型分布式架构都是靠多种语言和工具共同分工合作实现的

不是一两种工具或者语言能实现的如果专指php那是没有意义的

因为php本身只是一个单进程的东东,更别说分布式了

大规模的web应用以及分布式架构主要在于服务器的整体架构

1、web服务集群

2、数据库集群

3、分布式缓存

php充其量只是实现其中一个节点的某个具体的web应用

随着信息技术的发展，网络阅卷系统在各类考试中逐渐得到应用，减少了人工阅卷方式在试卷处理、试卷评阅及成绩处理等环节的工作量。高考改卷采用网络阅卷系统较早，由于受电脑数量、评卷教师人数等因素限制，高考改卷一般采用分科集中阅卷的方式，每个学科由300人至400人分组单独阅卷，后期通过人工合成各科成绩。由于集中式网络阅卷在人员安排、电脑配置上的局限性，因此，需要研究在教育城域网内如何实现分布式网络阅卷，解决更大规模人数的阅卷问题。下面以我市为例介绍解决方式。
台州市9个县区的学校有高中阶段每个年级各约2万考生，参加10个科目的统考。自2008年实施分布式网络阅卷系统（以下简称本系统）以来，台州市教育系统经过对本系统的多次调整优化，目前可以实现2400人同时评阅高中段6万考生的试卷，在2天内完成所有阅卷工作，并自动生成相应的学生成绩表及分析报表。本系统由网络系统、硬件系统及软件系统三部分组成。
一、网络系统设计
网络系统是实施分布式阅卷的基础，用于各个分布式阅卷点的网络接入。因为各个学校网络接入形式不一致，既有通过县区教育城域网统一出口的学校，也有直接接入互联网的学校。另外，各类考试的保密要求不同，如中考阅卷具有保密性要求，而高中期末考试则无相应要求。因此，本系统应考虑多种网络接入方式，无保密性要求的网络阅卷可通过互联网接入，具有保密要求的网络阅卷则可以通过专网接入，可采用MPLS 或SDH等方式通过光纤组网，确保系统运行时与其他网络物理隔离。
首先，需要考虑本系统网络的稳定性问题。由于SDH方式组网后对广播风暴抑制能力较弱，台州市中考阅卷采用MPLS 网络接入，每个县区设置一个接入点，用于当地阅卷客户端的接入及扫描数据上传。高中期末联考则采用MPLS 网络与互联网接入混合的方式。
其次，需要考虑本系统互联网出口带宽及MPLS 汇聚带宽的问题。经多次网络阅卷运行测试，每个评卷客户端在阅卷时主要传送试卷切分，所需平均带宽为40Kbps至50Kbps。台州市高中段一个年级2万考生所有学科评阅卷所需带宽约为72Mbps至80Mbps，按这样的带宽考虑本系统扩充问题，以及后期教育资源共享等应用业务的开展，互联网出口采用100Mbps专线，MPLS 网络采用1000Mbps专线。
二、硬件系统设计
1服务器系统
服务器系统包括数据库服务器、评卷服务器、图像服务器，是分布式阅卷软件运行的基础平台。数据库服务器为数据库系统的稳定运行提供保障，对CPU资源要求较高。本系统采用ORACLE 9i作为后台数据库。经实际测试，在2×2CPU+4G内存配置的单台服务器平台上同时进行高中段10个科目，每个科目单个年级段有2万条记录的网络评卷，系统运行稳定。评卷服务器实现网络阅卷界面的登录，主要负责>任务调度是日常开发中非常常见的一个业务场景。目前系统采用的是Quartz框架进行任务调度，但与业务系统耦合性太高，极端情况下，耗时任务甚至会耗尽调度线程，导致大量任务堵塞与延迟。也可能拖垮业务系统。

另一方面Quartz没有后台管理界面。问题定位排查 手动触发任务，随时修改任务执行时间等较难。

1：有良好的后台管理页面。

2：任务动态分片，数据庞大的大任务处理。

3：任务阻塞，路由及报警策略。

4：开发文档和社区完善。
此次主要对xxl-job(大众)，Elastic-job（当当），staturn（唯品会），lts，TBSchedule（阿里）五种调度框架进行综合对比。
e-Job和xxl-job都有广泛的用户基础和的技术文档，都能满足定时任务的基本功能需求。

e-Job已有2年左右没更新，社区也已经不维护，后续稳定性无法保证。

xxl-job 文档详细，且任务报警、阻塞及路由策略丰富，社区完善。

 因此采用xxl-job调度框架。
-路由策略：- 阻塞处理策略 -子任务：-失败报警 -分片广播 & 动态分片 等 

这里就不照搬官网参数，参考： >

如果大家了解微服务和分布式服务器架构等技术的话，那么对于如何解决系统运行中出现的BUG造成的破坏和损失这些问题也应该有自己独到的见解吧。今天，电脑培训就一起来了解一下，在服务器运行过程中出现的问题都有哪些解决方法。

随着微服务和分布式云架构的崛起，Web变得日趋复杂，“随机性”的故障因此变得越来越难以预测，而我们对这些系统的依赖却与日俱增。

这些故障给公司造成巨大损失，也给用户带来很大的麻烦，影响他们进行在线购物、交易或打断他们的工作。即使是一些简单的故障也会触及公司的底线，因此，宕机时间就成为很多工程团队的KPI。2017年，有98%的企业表示，一小时的宕机时间将给他们带来超过10万美元的损失。一次服务中断有可能让一个公司损失数百万美元。近，英国航空的CEO透露，2017年5月发生的一次技术故障造成数千名乘客滞留机场，给公司造成8000千万英镑的损失。

企业需要想办法解决这些问题，因为等到下一次事故发生就为时已晚。为此，混沌工程应运而生。

混沌工程旨在将故障扼杀在襁褓之中，也就是在故障造成中断之前将它们识别出来。通过主动制造故障，测试系统在各种压力下的行为，识别并修复故障问题，避免造成严重后果。

混沌工程将预想的事情与实际发生的事情进行对比，通过“有意识地搞破坏”来提升系统的d性。

混沌工程简史

混沌工程先出现在互联网巨头公司中，这些公司拥有大规模的分布式系统，因为这些系统太过复杂，他们需要一些新的手段来测试它们。

2010年

NetflixEngTools团队开发出了ChaosMonkey。当时，Netflix从物理基础设施迁移到AWS上，为了保证AWS实例的故障不会给Netflix的用户体验造成影响，他们开发了这个工具，用来测试系统。

2011年

SimianArmy诞生，在ChaosMonkey的基础上增加了故障注入模式，可以测试更多的故障场景。Netflix认为，云的特点是冗余和容错，但没有哪个组件能够保证100%的可用性，所以他们必须设计出一种云架构，在这种架构里，个体组件的故障不会影响到整个系统。

2012年

Netflix在GitHub上开源了ChaosMonkey，并声称他们“已经找到了应对主要非预期故障的解决方案。通过经常性地制造故障，我们的服务因此变得更有d性。”

2014年

Netflix团队创建了一种新的角色，叫作混沌工程师。BruceWong发明了这个角色，并由DanWoods在Twitter上向广大的工程社区推广。DanWoods解释说，“我从KoltonAndrus那里学到了更多有关混沌工程的知识，他把它叫作故障注入测试”。

2014年10月，当时Gremlin的联合创始人KoltonAndrus还在Netflix，他们在SimianArmy的基础上提出了故障注入测试(FIT)概念，开发者可以更灵活地控制注入故障的“杀伤力范围”。因为SimianArmy有时候会造成非常严重的故障，所以Netflix的开发者对它抱有疑虑，而FIT可以更好地控制故障粒度，于是他们就由此想出了混沌工程这个概念。

分清几个概念：分布式开发，分布式架构，分层开发。分布式开发是纵向以功能模块为单位分割软件，并以此分工的开发方式，尤其对大型开源的软件，开发者都身处不同地域，对各种功能模块的实现架构也有不同理解，但，模块开发完成提交后，有总构架师集成到系统中；分布式架构主要是为了web软件性能的优化而提出的软件结构方案与硬件配置方案；分层开发与纵向模块化相对，以横向分割软件，三层就是把软件横向分为三部分，每一层都有各种功能模块

---