直面PHP微服务架构挑战

在4月20日的阿里云栖开发者沙龙PHP技术专场上，云智慧Technical VP高驰涛为你们介绍了微服务的前世此生，分享了微服务架构实践中所面对的诸多挑战以及相应的应对策略。

本次直播视频精彩回顾，戳这里！
直播回顾：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的一个问题谈起，这个问题是“咱们的系统将会拥有五千个微服务组件。咱们应该怎么作？”你们能够仔细思考这个问题，咱们都知道一个接口确定没法称之为微服务，达到十几个接口或许才可以叫作微服务。那么，对于包含五千个微服务的系统而言，又该怎么实现和管理呢？其实，这样的系统背后会存在很大的问题。

本次分享将会主要围绕如下三个方面内容展开：

1. 微服务的前世此生
2. 微服务的挑战
3. 应该怎么面对

微服务的前世此生

下图所展示的内容其实能够说是供你们在茶余饭后聊天的谈资，若是想要知道微服务是如何诞生的，那么就必需要了解如下四个领域的知识。

TOGAF：全称为“开放组体系结构框架”，TOGAF在上世纪7、八十年代的时候就已经由专门组织负责开发了，但一直到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以及组织的管理人员而言，关系就很是大了。架构的转变须要考虑到信任危机、过时维护、多语言栈、沟通协做、安全网关以及轮岗结对等问题。

总结

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

原文连接 本文为云栖社区原创内容，未经容许不得转载。