Day 27 让我胆战心惊的微服务 Vol.1

来来来！小笠宏树 老师报名牌有没有在听！看这支，上礼拜老师讲过的，看到没有一直涨一直涨一直涨，你都不听那老师有什麽办法！

今天来分享个什麽呢～
The Offspring - The Kids Aren't Alright

好滴！看标题就知道要聊的是“微服务”，那至於为什麽是胆战心惊呢？这是因为我本身只是个Android工程师，因此我没有写过後端，也没有很熟微服务是什麽，所以我超怕讲错的ＸＤ。
那话又说回来为什麽身为Android工程师的我想硬是要聊微服务呢？这是因为前面的文章通常都是利用程序架构去了解公司的运作，顶多到两者互相应证的程度，因此在这个系列我希望带给各位读者的是利用公司的运作逻辑去理解一个新的程序架构可能产生的优缺点。但还是很抖啦ＱＱ，如果有讲错还麻烦各位读者留言讨论～

微服务

网路的定义

微服务 (Microservices) 是一种软件架构风格，它是以专注於单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模组化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通讯。（from Wiki百科)

好，看到这里，果然是个超出我理解范围的东西。让我来试着代换一下，恩～我看到了一些关键字像是“单一责任与功能”、“区块”、“组合”等等，感觉可以用子公司或公司分拆这件事来代入，其实应该也有其他类似的例子，但因为这个还没写过就先用这个吧～

公司分拆

目的

逻辑越来越复杂

• 公司角度
  • 公司的体质部门之间的沟通逻辑越复杂，很容易一个简单的合作要找到对应的资源要处理非常久，因此不如把几个较为重要的流程拆开来互相配合，举个例子：全家这间大公司将物流、系统、行销等等的不同功能拆分成不同的子公司，这时候假如行销需要客制化系统，那就去找负责做系统的公司。
• 微服务角度
  • 转而对於要做成微服务的理解就是，假如全部都是在同一个架构中，那这个架构会非常的复杂，而在要如何找到所需的、正确的资料或方法也会比较困难，因此不如拆开来变成多个微服务，每个服务负责自己的，这样架构上的耦合就会被强制分离，因此如果想要找到“使用者名称”的资料时，只需要看看跟“使用者”这个服务有哪一个沟通手段可以知道使用者名称就好。

定义规则麻烦

• 公司角度
  • 当公司越来越大，要定义公司文化或规则就会更加的麻烦，比如要如何订一个工时的规则是既符合物流产线员工和产品行销员工的，当没办法顺利的定出好的文化和规则，也就很难在各种的部门间都发挥出他们最大的产值。而拆分公司就可以有效的解决公司的核心业务不明确的缺点。
• 微服务角度
  • 当架构越来越大，每个地方要求的方向越差越多，有的是需要API回得越快越好，有的是记录要非常的小心，有的是需要多方去做沟通，此时如果要订一个大家都遵守的写程序逻辑会非常的麻烦，到底注重的要是速度？资料储存的大小？同步异步的处理？有太多需要注意的了，因此通常到最後就只能什麽都抓什麽都重要，意思也就是什麽都不重要，因此拆分成微服务，每个服务就可以专注自己核心的商业逻辑去做优化。

需求的资源不一

• 公司角度
  • 对於横跨上下游的公司来说，处理资源的分配是十分麻烦的一件事，比如物流应该是高资本低利润、但风险低的部门，而行销是低资本高利润、但风险高的部门，这时候将两者摆在同一间公司就会非常难分配资源，也会非常难以衡量两者的绩效。
• 微服务角度
  • 当架构越来越庞大也会发生一样的事，就纯粹以计算力来说好了，有的服务是需要稳定但少的运算资源，但有的服务是需要瞬间很多的运算资源，这时候要怎麽将这两者的资源统合做调度是十分麻烦的，但假如分开成不同的微服务，就可以知道要怎麽妥善地去处理运算资源分配的问题。

明天会来聊聊微服务的缺点