Day 28 让我胆战心惊的微服务 Vol.2

各位参赛选手～我是今天的主播 小笠宏树！各位准备好了！！！3 2 1 ～ 比赛开始！

今天来推脑洞神剧好了
Moonmen Music Video (Complete) feat. Fart and Morty | Rick and Morty | Adult Swim

今天要来进一步聊聊我根据分拆公司去推演微服务可能情况的第二部分。

缺点

• 沟通成本

  • 虽然昨天的文章有提到分拆可以将沟通的逻辑变简单，找到资源变容易，但假如我们将沟通分成前半部和後半部的话，分拆是将前半部变得异常简单，但後半部就会因为挂公司的关系而导致难度上升。
  • 程序的逻辑应该也会差不多，虽然微服务可以让你不用在茫茫的程序海里找，可以直接有个大方向找哪一个微服务，但後续如果需要多次沟通做客制化的部分就会很麻烦

• 区域最佳解

  • 虽然说拆分可以让各个子公司的核心业务目标越明确，这的确可以帮助子公司在优化自身业务时可以更方便，但是所谓的“区域最佳解”不一定是“全域最佳解”，有时候某一小部分的优化不代表是整体速度最快花费最少的方式。
  • 程序也是一样的，虽然微服务可以让架构变简单，因此优化逻辑容易，但牵涉到微服务间的互相配合的时候就不一定是最快的解法了。

• 资源分配问题

  • 通常对於公司来讲最重要的资源就是钱了，因此对於分公司来说分配资源有一个很好的比较基准就是赚不赚钱，当然就如同我们在财报那个所提到的可以用各式各样的比较基准去衡量每一间分公司。
  • 这点如同上面写的好像不是缺点，但是在程序中可是没有一个方便的东西来当作衡量基准的，因此要如何分配工程师在每一个微服务所要花的精力就是一件非常麻烦的事。

• 主控权

  • 通常当拆分成各个子公司一段时间後，就会期望各个子公司可以各自找到更多的生存方式，不论是从各个分公司中组合出新的产品，或是从外部接到新的客源，但这些做了之後反而会造成合作间困难，哪个产品是核心？如果我找物流子公司做事跟找外面的子公司一样要被加价没有人情价和客制化，那我还需要物流子公司吗？
  • 对於软件更是这样，拆成微服务的目的就是希望可以从中组合出更多产品的样貌，但假如真的产生更多的产品样貌了，那之後微服务该以哪个产品当主导权，比如：今天有一个产品的合作需要使用者微服务改变原本既有的API流程，并且使得使用它的其他产品都需要跟着变动，那它是改还是不改？那假设今天有100个产品都用同一个微服务，那这个微服务是根据这100个产品各种有些微差距的需求去做出“联集”的功能还是我只做出“交集”的功能，要用不用随便其他人？抑或是不那麽极端某些做“联集”某些取“交集”，那要怎麽定义这个“某些”？

• 重工

  • 这应该不用解释过多，拆分公司後每间分公司也会需要各自的人资、财会、行政等等重工的部门。
  • 程序也一样，每个微服务都必须处理各自的基础设定，像是网路服务、API介面、DB的处理等等。

• 知识领域的疆界

  • 当拆分成子公司後，同样的是将某些知识领域从原本的母公司拆分出去了，这时候要如何做出一个从生产到物流到行销都配合得恰到好处一个专案呢？可以认为一个专案要做得好可以不用所有的知识领域的配合吗？但假如需要深度的配合，就很有可能会又掉回第一点“沟通成本”的问题。
  • 微服务也是，当两个负责不同微服务的工程师要跟对方沟通，也会产生很多沟通障碍，由於不懂的对方微服务的知识，因而很有可能设计出不合适的API沟通方式。

市面上的解法

• 事业群负责人 - 将多个子公司的负责人都挂同一个。

  • 这个是为了解决“沟通成本”、“区域最佳解”、“资源分配问题”、“主控权”和少少的“知识领域的疆界”，可以利用这个负责人来处理跨子公司之间的知识问题，或是子公司之间的配合问题。
  • 从软件的方法解释这件事也很简单，就是会让好几个微服务都给同一个工程师管，甚至是交错管理以便产生更好的配合和分工，比如：Ａ工程师管a、b微服务，B工程师管b、c，C工程师管a、c。
  • 还有一种跟事业群负责人蛮像的是叫做对接窗口，他们会是有着其他子公司知识的人来其他常合作的子公司当沟通窗口，当然他没有主控权，但可以弥补在“沟通成本”、“区域最佳解”和“知识领域的疆界”这些部分

• 控股公司 - 成立另外一家控股公司用以负责投资每间集团子公司。

  • 这个是为了解决“区域最佳解”、“资源分配问题”、“主控权”，可以利用这个控股公司来控制整体子公司的前进方向。
  • 从软件的角度可能是人为的上司的命令，比较体制化可能会是PM会先开个会确定这次产品前进的方向会需要哪些微服务，然後看要投资多少人力在哪些微服务上。

• 母公司 - 就是产品的需求来源都来自同一个，其他公司只是辅助的角色。

  • 这个是为了解决“沟通成本”、“区域最佳解”、“资源分配问题”、“主控权”，母公司有很大的权力去要求子公司去配合它的需求，因此也会安插很多母公司的管理直到子公司，因此沟通成本可以降低，主控权也会极高。
  • 对於软件来说就是所有微服务基本上还是只为了一个大的产品需求跑，但这个的後果很容易就是有拆等於没拆，基本上还是被当作同一套软件在运作，个人不推荐但很常见。

• 外包 - 子公司都只用外包的方式在处理其他人的需求

  • 这个是为了解决“沟通成本”、“资源分配问题”，这种方法的主控权很低，基本上就是与另外一间公司合作的感觉，但在沟通上因为会有外包的一套SOP，因此沟通上会比较容易（要嘛接受要嘛找别人），也会有另外一个好处是，子公司如果能做到这个程度也就可以没有任何负担的接外部的客户。
  • 意思就是将微服务之间的耦合程度降到最低，基本上只能靠着特定几个不变的API做沟通，因此就解决了沟通成本这件事，但微服务之间会很难配合新的弹性化的需求，但基本上这个微服务也可以开放给外部使用了。

糟糕的状况

• 遇过几个还蛮不好的例子的，这边就叙述它们遇到的情况

1. 母公司要求就一定要做到，赔本也要做。
2. 每年其他公司都会给订单，所以子公司的效率极差。
3. 之间由於知识差太多，反而会花很多时间在来回开会上。
4. 产品端时常觉得各个子公司的配合度极差。
5. 母公司的分配资源方式不公平。

PS：在写区域最佳解的时候很有感，所以不得不来写一段数据分析式的管理学
可以将公司想像成一个有深度的模型
当是一间大公司时这个模型就会是非常深的
此时假如一个非常深的模型想要到达预测的最佳解，只要投了足够多的数据量（钱）、人力和物力，总是能在千辛万苦後还是能达到最佳解。
而如果将大公司这个模型拆成很多小模型（子公司），再用线性回归的方式串起来，那每个模型其实不用很多的资源就能达到最佳解了，但此时的最佳解跟大公司模型比起来还是输了一节。
但这时候还是要注意一点，模型也不是越深越好，最直接的一点数据量（钱）、人力和物力都不是无限的，因此管理者始终要在一个大公司以及多个小公司之间做时机和市场上的抉择。

好啦～由於想到一大堆害我打了好多字。
明天就是倒数第二篇了
会来讲些比较软的事情
明天的题目是“软件教我的那些人生守则”