岗位信息
职位：PHP架构师
工作职责：
- 负责应用类产品后端架构设计、开发与优化
- 负责业务整体设计，具有良好的维护性和扩展性
- 参与需求分析与评审，了解业务，从技术角度推进业务的安全、稳定运行
任职要求：
- 掌握微服务开发，拆分，saga事务模型
- 掌握消息队列
- 熟悉其他的语言
- 掌握docker，k8s
- 熟悉TCP、UDP、http协议
- 熟悉 linux 基础命令，了解如何排查系统性能瓶颈
- 熟练掌握mysql数据库的性能优化，表拆分
- 熟练掌握php，了解PHP的优势
- 统招全日制本科及以上学历，理工科专业。
知识点
saga 事务模型
概念
saga 是啥？ 咱可没听过呀。
《传奇》是由布莱恩·K·沃恩（Brian K. Vaughan）撰写并由菲奥娜·斯台普斯（Fiona Staples）绘制的史诗般的太空歌剧/奇幻漫画系列，由美国公司Image Comics每月出版。该系列作品深受《星球大战》（Star Wars）的影响，并基于沃恩（Vaughan）既是孩子又是父母的想法。
—— saga
呃，貌似对找工作没啥帮助，既然是漫画先收藏起来。
再搜找到了以下相关的介绍：
1987年普林斯顿大学的 Hector Garcia-Molina 和 Kenneth Salem 发表了一篇 Paper Sagas（点这里可以看原文），讲述的是如何处理 long lived transaction（长活事务）。Saga 是一个长活事务可被分解成可以交错运行的子事务集合。其中每个子事务都是一个保持数据库一致性的真实事务。
The Saga design pattern is a way to manage data consistency across microservices in distributed transaction scenarios. A saga is a sequence of transactions that updates each service and publishes a message or event to trigger the next transaction step. If a step fails, the saga executes compensating transactions that counteract the preceding transactions.
Saga 设计模式是一种在分布式事务方案中跨微服务管理数据一致性的方法。 saga 是更新每个服务并发布消息或事件以触发下一个事务步骤的事务序列。 如果步骤失败，saga 将执行补偿事务，这些事务会消除前面的事务。
—— Saga distributed transactions pattern - Azure Design Patterns
You have applied the Database per Service pattern. Each service has its own database. Some business transactions, however, span multiple service so you need a mechanism to implement transactions that span services. For example, let’s imagine that you are building an e-commerce store where customers have a credit limit. The application must ensure that a new order will not exceed the customer’s credit limit. Since Orders and Customers are in different databases owned by different services the application cannot simply use a local ACID transaction.
Implement each business transaction that spans multiple services is a saga. A saga is a sequence of local transactions. Each local transaction updates the database and publishes a message or event to trigger the next local transaction in the saga. If a local transaction fails because it violates a business rule then the saga executes a series of compensating transactions that undo the changes that were made by the preceding local transactions.
你已经使用了 Database per Service 模型，每个服务有自己的数据库。然而有些业务的事务是跨多个服务的，所以需要一个实现跨服务的事务机制。 例如你在创建一个客户有信用限制的电商系统，系统必须确保新创建的订单不会超出客户的信用限制。但是因为订单和客户在不同服务的数据库中，系统就无法简单的使用本地 ACID 事务。
实现业务事务跨多个服务执行就叫 saga。Saga 是一个本地事务的序列。每个本地事务更新数据库，并发布一条消息或事件，以触发 saga 中的下一个本地事务。如果本地事务因违反业务规则而失败，那么 saga 将执行一系列补偿事务，这些事务将撤销之前本地事务所做的更改。
saga 事务有两种恢复策略
向前恢复（forward recovery）：
对于执行不通过的事务，会尝试重试事务，这里有一个假设就是每个子事务最终都会成功。这种方式适用于必须要成功的场景。
向后恢复（backward recovery）：
在执行事务失败时，补偿所有已完成的事务，是“一退到底”的方式。
saga 事务协调
Choreography（编排）:
参与者（子事务）之间的调用、分配、决策和排序，通过交换事件进行进行。是一种去中心化的模式，参与者之间通过消息机制进行沟通，通过监听器的方式监听其他参与者发出的消息，从而执行后续的逻辑处理。由于没有中间协调点，靠参与靠自己进行相互协调。
优点：
-
简单：每个子事务进行操作时只用发布事件消息，其他子事务监听处理。
-
松耦合：参与者（服务）之间通过订阅事件进行沟通，组合会更加灵活
缺点：
-
理解困难：没有对业务流程进行完整的描述，要了解整个事务的执行过程需要通过阅读代码完成。增加开发人员理解和维护代码的难度。
-
存在服务的循环依赖：由于通过消息和事件进行沟通，参与者之间会存在循环依赖的情况。也就是A服务调用B服务，B服务又调用A服务的情况。这也增加了架构设计的复杂度，在设计初期需要认真考虑。
-
紧耦合风险：每个参与者执行的方法都依赖于上一步参与者发出的消息，但是上一步的参与者的所有消息都需要被订阅，才能了解参与者的真实状态，无形中增加了两个服务的耦合度。
Orchestration（控制）:
saga 提供一个控制类，其方便参与者之前的协调工作。事务执行的命令从控制类发起，按照逻辑顺序请求 saga 的参与者，从参与者那里接受到反馈以后，控制类再发起向其他参与者的调用。所有 saga 的参与者都围绕这个控制类进行沟通和协调工作。
优点：
-
避免循环依赖：在编排模式中存在参与者之间的循环调用，而中心控制类的方式可以避免这种情况的发生。
-
降低复杂性：所有事务交给控制器完成，它负责命令的执行和回复的处理，参与者只需要完成自身的任务，不用考虑处理消息的方式，降低参与者接入的复杂性。
容易测试：测试工作集中在集中控制类上，其他服务单独测试功能即可。
- 容易扩展：如果事务需要添加新步骤，只需修改控制类，保持事务复杂性保持线性，回滚更容易管理
缺点：
-
依赖控制器：控制器中集中太多逻辑的风险。
-
增加管理难度：这种模式除了管理各个业务服务以外，还需要额外管理控制类服务，无形中增加了管理的难度和复杂度。而且存在单点风险，一旦控制器出现问题，整个业务就处于瘫痪中。
总结
首先Saga是针对分布式长活事务的解决方案，针对事务长、多、复杂的情况，特别是服务由多个公司开发具有不可控性，可以使用Saga模式进行分布式事务的处理。Saga在处理事务一致性方面采取了向前恢复和向后恢复策略，前者通过不断重试的方式保证事务完成，而后者通过子事务的补偿事务，逐一回滚的方式让事务标记失败。在分布式协调方面，Saga采用了两种模式：编排和控制。前者让参与者（服务）之间通过消息进行沟通，根据事件出发事务的执行流程，是一种去中心化的模式。后者通过中心控制类，处理事务的执行和回滚步骤，统一调用服务和接受服务的反馈。
微服务
Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of services that are
- Highly maintainable and testable（高度可维护、可测试）
- Loosely coupled（松耦合）
- Independently deployable（可独立部署）
- Organized around business capabilities（围绕业务能力进行组织）
- Owned by a small team（由一个小团队拥有）
The microservice architecture enables the rapid（快速）, frequent（频繁） and reliable（可靠） delivery of large, complex（复杂的） applications. It also enables an organization to evolve（改进、演化） its technology stack.
消息队列（Message Queue）
能够在服务集群中广播消息，并传递到每个服务中。具有这个功能的像是 NSQ 或是 RabbitMQ。你能够在 A 服务上广播一个“创建新用户”的事件，这个事件可以顺便带有新用户的资料。而 B 服务可以监听这个事件并在接收到之后有所处理。这些过程都是异步处理的，这意味着 A 服务并不需要等到 B 服务处理完该事件后才能继续，而这也代表 A 服务无法获取 B 服务的处理结果。与事件存储中心近乎相似，但有所不同的是：消息队列并不会保存事件。一旦事件被消化（接收）后就会从队列中消失，这很适合用在像发送欢迎信件的时机。
—— 微服务