php微服务架构有哪些直面PHP微办事架构挑衅

本次直播视频精彩回顾，戳这里！

直播回顾：https://yq.aliyun.com/live/965

PPT分享：https://yq.aliyun.com/download/3527

以下内容根据演讲视频以及PPT整理而成。

高驰涛 (Neeke Gao)，云聪慧Technical VP，PHP/PECL开拓组成员，具有10余年研发管理履历，同时也是PECL/SeasLog、PECL/JsonNet、GoCrab等多项开源软件的作者。
2014年加入云聪慧，致力于APM与大数据产品的架构研发，崇尚敏捷、高效。

从一个问题谈起

首先，从几年之前某CTO的一个问题谈起，这个问题是“我们的系统将会拥有五千个微做事组件。
我们该当怎么做？”大家可以仔细思考这个问题，我们都知道一个接口肯定无法称之为微做事，达到十几个接口或许才能够叫做微做事。
那么，对付包含五千个微做事的系统而言，又该怎么实现和管理呢？实在，这样的系统背后会存在很大的问题。

本次分享将会紧张环绕以下三个方面内容展开：

下图所展现的内容实在可以说是供大家在茶余饭后谈天的谈资，如果想要知道微做事是如何出身的，那么就必须要理解以下四个领域的知识。

TOGAF：全称为“开放组体系构造框架”，TOGAF在上世纪七、八十年代的时候就已经由专门组织卖力开拓了，但一贯到1995年的时候，美国国防部参与之后，TOGAF才终极成型。
举例而言，大家手机里正在利用的产品和运用中，很多都会用到SAP、IBM或者惠普等的软件，而这些软件公司所遵照的便是TOGAF。
可以说目前环球超过50%的企业正在利用TOGAF实践软件架构设计和开拓。
TOGAF是一个架构体系，而并没有供应详细的架构方法。
TOGAF包含了业务架构、运用架构、数据架构、技能架构等，实在，阿里云的全局组件也属于TOGAF中的技能架构领域，其能够帮助客户减少各种繁杂的思考，使得客户只须要关注于业务架构即可。

TOGAF有三个最为紧张支柱：

1)企业架构域，紧张是企业信息与业务流等；

2）ADM一系列的架构方法论；

3）企业连续性，指的是在企业业务高速增长并且也不断变更的过程中，担保架构体系的连续性。

DDD：全称为“领域驱动设计”，其包含了诸多的观点，但是大家只须要记住紧张的三句话即可。

1）DDD是精简的业务，DDD首先关注的便是业务，把各种繁琐的业务流程精简成更细的链条；

2）DDD须要回答业务是干什么的，能够知足什么需求，达成什么目的；

3）不断迭代，DDD的不断迭代与TOGAF的企业连续性类似。

SOA：全称为“面向做事架构”，其理论也非常多，但是大家也只须要记住三点。

1）SOA办理了信息孤岛的问题，不让信息变成孤岛；

2）业务重用，从业务角度将各个做事组合成一个个中间件或者做事，将其供应给用户或者其他系统；

3）SOA使得系统成为互联互通的信息群。

GRASP原则：全称为“通用职责分配原则”，实在很多大家耳熟能详的观点如“低耦合”、“高内聚”都来自于GRASP原则。
其与设计模式不同，设计模式辅导如何实现系统，而GRASP辅导如何划分。
GRASP原则辅导定义业务架构以及API等干系内容和划分做事，其理论内容也非常多，但是只须要记住三个关键：

1）自己干自己的事；

2）自己只干自己能干的事；

3）自己只干自己的事，强调了资源划分。

在软件工程的教科书上给出了微做事架构的定义：微做事架构是一种架构模式，它提介将单一运用程序划分成一组小的做事，做事之间相互折衷、相互合营，为⽤户供应终极代价。
每个做事运行在其独立的进程中，做事与做事间采取轻量级的通信机制相互沟通(常日是基于HTTP协议的RESTFul API)。
每个做事都环绕着详细业务进⾏构建，并且能够被独⽴的支配到⽣产环境、类⽣产环境等。
其余，应该只管即便避免统一的、集中式的做事管理机制，对详细的一个做事⽽言，应根据业务高下⽂，选择得当的措辞、工具对其进行构建。
而这些教科书上的内容或许在当下来看已经由时了。

那么，我们利用微做事架构的时候，到底得到了什么东西呢？实在得到了很多，这里为大家总结了四点最为明显的优点。

1）使得开拓和迭代变得更加敏捷，利用微做事架构使得敏捷开拓成为可能；

2）易于扩展和紧缩，一些公司基于Kubernetes、Docker等技能可以在几秒内拉起上万个微做事，昔时夜型流量冲击到达的时候，可以实现无损地承担全部流量，同时实现用户无感知，而当数据访问量降落之后，又可以实现快速缩容；

3）多技能栈可能，目前聪慧云的技能栈非常全面，虽然开拓职员只有60多人，但是开拓措辞却多达10多门，而利用微做事可以有效地组织各种开拓职员；

4）高可修正性，比如实现数据库的快速迁移，通道的快速切换等。

这里再提出两个问题，虽然微做事能够带来诸多优点，但是也存在两点疑问。
第一个便是“微做事架构，你的系统变得更健壮了吗？”；第二个则是“利用微做事让系统变得更快了吗？”对付这两点而言，可能说是见仁见智的。
有人说由于组件变得越来越多，可监控性就会变难，因此系统健壮性就会变得越来越差，也有人说由于将系统拆分得越来越细，因此健壮性就会越来越强。
如果单体架构是串行的，那么利用微做事可以将其变成并行的和分布式的，而多个组件之间进行通信，也会使得通信成为性能瓶颈，那么利用微做事到底是变快了还是变慢了呢？这两个问题都很难以回答。
而作为一个架构师或者开拓者须要进行深入的思考。

微做事架构面临的寻衅和思考

这里为大家总结了在利用微做事架构的时候所须要面临的8条寻衅和干系的思考。

1. 小即是多

当业务从大变小的时候，也意味着业务变多了。
由大变小，可以使系统变得更加随意马虎掩护和修正，但是由少变多，又会使得问题更加繁芜，因此也会有很多的寻衅。
第一个问题便是多节点、多做事和多状态。
系统中的节点、组件做事变得更多了，那么节点和做事之间的状态也会变得更难掩护，更加繁芜。
基于前面提到的四种知识，实在可以将从大变小和从少变多这两个转变进行折中，使得其变得更加可控。
而办理这个问题的关键在于对付做事的合理拆分，紧张有三点可以考虑，即数据资源、业务功能以及做事工具。

2. 债务管理

比如Bug、代码毛病、未完成的功能或者版本不兼容等问题都是债务。
当做事变得越来越多的时候，债务每每就会变得更多。
为理解决这些问题，实在有这样的几种策略，比如单元测试，如果单元测试做的足够好，那么代码毛病的可能性就会变得更低一些，可以将做事由少变多所造成的债务变多情形进行收敛；集成回归，这部分供应了很多工具去做这件事情，不用开拓者自己去做；版本管理，这里指的是静态库的版本管理，动态库指的是正在变更中的库，而静态库指的是不再变更的库和配置项，这一点掌握不好，就随意马虎使得系统管理混乱；迭代冲刺，这是一种组织办法，当有很多技能债务须要进行管理时，如何将这些债务一点点处理掉或者把发散的趋势收敛住，迭代冲刺便是一种做法；Bug Crash，这是聪慧云团队自己发明的一个名词，相称于是对付Bug的大肃清，无论采取传统的还是敏捷的开拓模式，都有一些Bug存在，因此定期会组织全体开拓和测试以及产品将自己的产品用一遍，进行Bug大肃清；回归总结，无论采取什么开拓模式，在一个迭代周期完成之后，回归总结是少不了的，也须要通过一些方法办理新发生的问题，或者将其封闭住不使债务连续蔓延。

3. 繁芜的做事依赖

如果只有一个或者几个组件，那么实在不存在做事依赖问题，而如果有几千个组件，那么做事依赖将会成为巨大的问题。
举例而言，如果用户做事须要调用订单做事，那么在启动的时候须要进行一些初始化任务，那么一个做事的版本发布可能导致系统全面瘫痪，这便是繁芜做事依赖问题。
为理解决这个问题首先就须要做事创造机制，比如利用etcd或者Zookeeper等，首先做事创造中央也须要是分布式高可靠的，那么做事起来之后须要把自己的名字和调用办法见告做事创造中央，注册上去，对付做事调用者而言只须要从做事创造中央那里通过约定好的名字获取做事调用地址即可。
依赖唤醒是有一个相比拟较新的东西，比如大流量溘然打进来的时候，A做事须要从原来的10个启动到100个，而B从原来的3个肯定也是不足用的，因此须要通过唤醒的机制将做事拉起来，而不是被动的被关照。
还有一种情形也须要利用到依赖唤醒机制，比如缓存穿透问题，正常情形下，缓存是生效的，不会存在穿透的情形，但是可能由于某种非常使得缓存不生效了，会将大量的流量打到DB里面去，使得做事变得不可用了，全体做事雪崩掉，针对这些问题一样平常会开拓一些挡板做事，可能会给出一些固定的数据，而这些挡板做事也有可能会面临这种突发的流量也须要通过依赖唤醒的机制实现唤醒。
此外，还有灰度发布和AB测试，这两点是干系联的。
还有多版本共请安题，对付做事的多版本也是一个技能债务问题，须要考虑如何将其旧版本拿下来。

4. 通讯

如果系统中包含多个措辞栈，多种实现办法。
那么统一标准是必须的，要么统一一种RPC或者就利用RestFul API等。
中央也是一种处理做法，这一点在Java中运用很多，中央并不是行列步队，而是一个事宜驱动的中央。
此外，还有通讯网关，这在利用微做事的时候也是一个必要点，其紧张办理了监控问题，而且可以通过网关起到中控的浸染，比如安全、性能以及用户校验等任务。

5. 分布式事务

在实现分布式事务的时候可以采取2PC或者3PC原则来实现，2PC原则是通过全部节点投票和实行两个步骤完成的，并且是壅塞的；而3PC则不同，虽然在一个详细的事务里面可以是壅塞的，也可以是非壅塞的。
3PC协议则是通过“Can-Pre-Do”三个步骤来实现的，实在PDU便是3PC协议在单体中的实现办法。
而在分布式系统中，3PC有三种实现办法，利用分布式的事宜驱动、最大关照以及两阶段补偿TCC。

6. 花式故障

很多时候，当系统涌现问题可能须要花费数周和很多人力才能找到根源所在，可能由于系统太多，使得系统架构师也无法清楚系统与系统之间的关系。
面对诸多的花式故障，也有多种策略可以应对，比如全链路追踪，比如利用Open Tracking；主动拨测，很多用户真个APP里面内置探针，使其可以吸收Server真个指令来定期探测接口和做事是否正常。

7. 中央与去中央

中央与去中央可以算是一个永恒的话题，上图中展示的配置、发号、日志、调度、状态以及预警，实在对付比较成熟的大型系统而言，这六点都是须要中央的。

8. 组织危急

末了一个问题，也是最大的问题。
实在要实现向微做事架构的变更的时候，最大的问题便是组织危急。
这一点与开拓者关系不大，但是对付Team Leader以及组织的管理职员而言，关系就非常大了。
架构的转变须要考虑到信赖危急、过期掩护、多措辞栈、沟通协作、安全网关以及轮岗结对等问题。

总结而言，最主要的不雅观点有两个：微做事不是银弹。
不要让重复的事情做两次。

作者：PHP小好手