状态机的理解与应用场景?

• 資深大佬 : opengps

  状态机解决的是站点集群共享会话问题，在集群环境下，多个 web 负载机（无状态）可以更好地使用弹性伸缩，零活增加 web 机器数量来增加负载，但是对于会话状态，则需要：A 定向到某台机器 或者 B 共享到一个地方
  解析：
  A 定向到某台机器的做法，在负载均衡处可使用“改写 cookie”
  B 共享会话状态，则统一从“状态服务器”获取。也就是你说的状态机

• 資深大佬 : zoharSoul

  比如交易订单状态流转

• 主 資深大佬 : beryl

  @zoharSoul  查了一些资料，也大都是运用在交易系统，我们目前不是这种系统，而且有多种实体，流程状态可能也要比交易要复杂

• 主 資深大佬 : beryl

  @opengps 如果按照这种理解，感觉当前系统不适合。我再研究研究

• 資深大佬 : reus

  能不能不要乱用名词？
  状态机就是状态机，你这个叫状态服务器！
  不要用不同的概念去污染名词！

• 主 資深大佬 : beryl

  @reus 不是状态服务器，还是想着用状态机的概念去处理服务
  #1 的概念我理解是状态服务器

• 資深大佬 : hugedata

  主和一说的“状态机”可能和我理解的状态转换的状态机（ State Machine ）不一样……

• 主 資深大佬 : beryl

  @hugedata 那换个问法：
  State Machine 的应用场景是什么呀，还是只是概念术语

• 資深大佬 : catror

  7 +1，看得我一脸懵逼

• 資深大佬 : timsims

  主不如简述一下你想通过你所指的 “状态机” 解决怎样的问题

• 主 資深大佬 : beryl

  @timsims 嗯呢，补充了下问题

• 資深大佬 : opengps

  看了 append，文中“状态机”不是我理解的状态服务器

• 資深大佬 : zlowly

  为什么我感觉题主描述的场景更接近于工作流引擎？

• 主 資深大佬 : beryl

  @zlowly 是想着 workflow 和 state machine 结合的方案

• 資深大佬 : jintianfengda

  状态机就是用来维护实体的状态的玩意，当一个实体的状态比较多且比较复杂的时候，都可以引入状态机来统一管理状态流转，通过”动作”来进行状态的变更，我理解这个 statemachine 这个跟架构有一丢丢关系，但是不大，跟一说的状态服务器不是一个东西

• 資深大佬 : Lonersun

  您看看这篇文章，不知能不能解答一些你的问题 https://juejin.im/post/6844903817192947726

• 資深大佬 : imn1

  比较关键是状态有限（可以全部列举），每个状态都是固定的，只会出现不同的状态，而单个状态本身不变
  服务器场景我不熟，但可以从其他方面说一下问题 2

  1.有序的状态切换，这个有序是固定的、必经的，每个状态都要轮训一遍
  例如上述订单流程

  2.无序但有限几个状态之间无级切换，每次状态改变需要做固定接口的处理
  例如有限个外观主题之间切换
  我在一个 GUI 项目里面用了十多个状态机，处理一些独立的控件 event，这些控件不会和其他控件组合，一旦改变就会直接执行程序，这样只要控件的参数值有限，类型只有一个，多少个参数值就是多少个状态了

  其实可以这样说，GUI 的控件都是固定的，程序就是处理控件产生的参数改变和组合而已，理论上可以全部用状态机写，理论上；只是有些参数值和类型太多，多个控件组合出来的状态可能无穷多，状态机无法全部列举而已

  状态机是省代码和省思考，因为状态固定，状态进出处理的函数也固定（不太复杂），要想的就是状态变化的可能，穷举列出来而已
  目前我所知的状态机处理第二种还是比较麻烦的，例如 3 种状态，要列明 1-2, 2-1, 1-3, 3-1, 2-3, 3-2 等所有排列组合情况，比较好的是如果这些 123 状态只是简单的标识区别，可以 for+排列组合 来完成这个定义，如果复杂一些就不好使了，还不如写个变参函数方便

  顺便也举个不适用例子，也是这个 GUI 项目，最初想把语言切换（汉英）也写成状态机，后来考虑到将来要增加语言（日韩……），而且语言变化还有细微不同（状态不完全固定），感觉用状态机是给自己挖坑，就放弃了，改用事件信号+函数

• 資深大佬 : zhuangzhuang1988

  https://learnyousomeerlang.com/finite-state-machines

• 資深大佬 : chanxiaoxi

  我猜你说的是 State Pattern 设计模式

• 資深大佬 : Ariver

  工作流啊

• 資深大佬 : lzxz1234

  适合场景：复杂流程对象，例如特殊类型订单，三个参与方以上的订单，用户下单，用户撤回、客服打回、商家拒单就是三个，再加上不同状态允许操作的人员不一样，很容易堆出各不相同的几十种状态来

  纯在代码靠 if else 复杂度极高，维护过程新加角色、状态或者 几条操作路径都可能导致工作量爆炸

  至于微服务和状态机的关系，这个其实没关系，更取决于业务复杂度

  资料直接看工作流就可以

• 資深大佬 : sampeng

  此机非彼机…看到机字就是机器是么

• 資深大佬 : reus

  @beryl 用规则引擎啊，把所有规则都写下来
  新建 app 需要什么要素，满足了才能新建
  上线需要什么条件，满足了才能上线，等等
  直接搬运现实的办事方式就行，需要什么材料，需要哪里盖章，都完备了，就可以办某件事
  不用管什么状态机，只有两种状态：条件够了，能办，条件没够，不能办。
  例如一个事情需要盖十个章，你不需要把每一种盖章组合都搞出一个状态来，你只需要说，缺哪些，不能办，就够了
  状态机这个模型，用来描述业务是不适合的，它只适合微观的场景，例如 TCP 状态机这类几十年不用变的。用状态机描述业务，一旦业务流程变了，整个状态机都要改，麻烦得很。

• 資深大佬 : liuhuan475

  你说的状态机是这个吗？ https://www.bilibili.com/video/BV1Eb411U7z8?p=95

• 資深大佬 : ieiayaobb

  电商业务，订单系统是个很经典的 state machine

• 資深大佬 : THESDZ

  将这种服务抽离成单独的服务,看业务,可以进行读写锁,大概就能满足你的需求了

• 資深大佬 : THESDZ

  @THESDZ 或者直接用 redis 做为 k-v 存储,业务逻辑交给业务代码处理?

• 資深大佬 : amoyiki

  大家有在生成上面有过 状态机吗？目前我还是用 if else

• 資深大佬 : gaius

  就是独立订单服务，有啥问题。服务只是计算，实际的状态机是后面的数据库

• 資深大佬 : SurfaceView

  我做过几个。。
  1 个是播放器的 1 个是下载系统
  都深度依赖状态机 （非状态模式

• 資深大佬 : useben

  我理解的状态机是分布式系统中的状转移个同步..

• 資深大佬 : SmiteChow

  常规情况下要考察控制流是否经常变动,如果控制流经常变动,那么使用状态机更合适.
  如果不怎么变动,那么直接硬编码控制流为编程语言语法即可.