01 | 原始分布式时代：Unix设计哲学下的服务探索

1.这个简单需要从两方面来看待，分别是业务和技术。 2.先说业务。现代的软件系统的业务复杂性越来越高。而分离关注点无疑是应对日益增长的业务复杂性的有效手段。但如果依旧是是一个大单体系统（所有业务单元都在一个容器下），那么跨业务单元的知识诉求便很难避免，并且开发迭代以及版本发布中彼此还会相互影响。而微服务的出现为其提供了设定物理边界的技术基础。使得多个特性团队对业务知识的诉求可以收敛在自身领域，降低单个特性团队所需了解的业务知识。 3.再说下技术。这里我认为主要提现在技术隔离上。就像rpc让你像调用本地方法一样调用远程方法，微服务技术组件的出现，大多是为了让开发人员可以基于意图去使用各种协调分布式系统的工具，而不用深入具体工具的实现细节去研究怎么解决的分布式难题。 4.同时就像sprngboot提到的生产就绪，微服务的生态已经不局限于开发的阶段。在部署和运行阶段都有健全组件支持。它可以让开发人员基于意图就可以简便的实现金丝雀发布，基于意图就能拿到所有系统运行期的数据。所有的这些便利都算是技术隔离带来的好处。

就我个人而言，我对"微服务中的简单"的理解，是指微服务中的每个服务，每一个中间件，服务中的每个接口，都是"简单"的，同时也应该以”简单“作为目标进行设计。 正如很多前辈所言，微服务的出现，目的为了弥补单应用中存在的各个缺陷，如业务功能过多导致代码的耦合度很大，某个功能使用频繁高，占用资源多（本身这个功能可能跟业务无关，但是因为占用大量资源导致整个系统不可用）等等。 这个时候，我们可能会基于业务功能，对应用进行拆分，把每个业务拆分出来，做成一个微服务应用。功能模块的拆分有几个好处，一是在开发团队人员充足的情况下，每个人需要维护的代码变简单了，二是整个系统解耦了，每个服务也可以互相调用，换句话说就是系统的复用性变高了，三是，在单个微服务变得不可用的情况下，如果配置的好，是不会影响整个系统正常运行，从一定程度上提高了系统的可靠性和可用性。 基于这个思路，我想中台和serveless的诞生，也是基于这些准则，比如在后期发现，随着业务不停扩展，代码中有好多功能是通用的，那么是不是可以把这些这些代码抽出来，做成一个个模块，给各个应用级的微服务应用进行调用呢？（基础平台的职责） 当然，也正如老师所说的，就从整个架构来说，其实微服务并不是这么简单的，既然拆分了应用，那么不可避免的，你就会遇到这些问题： 1. 各个微服务之间怎么知道接口的地址在哪（服务发现和服务注册中间件） 2. 服务之间该用什么协议进行通讯和接口的调用（rpc调用中间件） 3. 某个服务突然不可用了，我又不能影响整个系统的可用性，我该怎么办（服务降级，熔断） 4. 为了提高某个服务可用性，我做了集群（同样的服务，在不同的节点开了应用），我该怎么分配落在这个集群中的请求（负载均衡中间件） 5. 外部怎么能够访问这个系统中的某个微服务（网关中间件）等等（如分布式系统中的锁设计和事务实现） 总而来说，“微服务的简单”，这个命题还挺有意思的，它就像一个有多个pics的乐高模型一样，对于每个pic的积木而言，确实很简单，但是就整体而言，它是由多块积木拼起来的，往往就比较，复杂，也需要我们去花心思去思考，去完成。 我觉得"简单"二字，不仅仅一门艺术，同时也很考验我们程序员的技术和设计能力。我想这也是大部分程序员的目标和初衷吧。 PS: 有幸能够在这里看到老师，之前有拜读过老师的《机器学习》（在看，没看完）和《深入理解jvm》，确实让我受益匪浅，从书的目录设计来看，我觉得老师很用心而且也很厉害。同时也有个小建议跟大家分享，在读《深入理解jvm》那本书的时候，不妨按照这个思路去阅读：.java文件是怎么生成的 -> javac编译器是怎么生成.class文件的-> 类加载器是怎么加载类的 -> 对象是怎么生成的 -> 对象在内存中是怎么调用的 -> 对象是怎么回收的，往这几部分去填充书中的内容，就可以形成一个体系了（我是这么做的）

计算机技术一个关键命题是使用有限的“成本”尽可能“高效(性能)”的解决“复杂(度)“问题。 分布式的初期探索，其实就是在单机性能有限的情况下，期望通过“集群化”、“分离变化点”的架构手段来提升性能，但由于时代限制，这条路线的成本过高，同时随着摩尔定律+时间，性能问题在单机上得到了阶段性解决，所以才有了后面的单体时代。 但要解决的复杂度随着时代发展爆炸性增长，摩尔定律+时间这一法宝也日渐失灵，人们其实也不得不回到分布式这条路线上，于是有了后面微服务，云原生的故事。

所谓的“简单”，是单个业务的简单。 现在的编程——面向接口编程——“万物皆接口” 回归到本质，便是把一项复杂的业务，化整为零，转化为一个个接口。 例如——“转账”业务，其本身对外就是转账接口。 但是往下层，可能就是一个资金转入转出接口。 转入转出操作之前可能是一个校验接口，校验转出账户余额是否充足，校验目标账户是否有效。 转出转入金额操作的同时，又要调用留日志接口。 再额外又有通知目标用户的接口...... 每一个接口，其实都很简单（用一句话即可描述接口要实现的业务） 接口要可以用一句话，甚至一个词，来描述，这也是之前学习到的接口设计的逻辑规范。 比如登陆接口，就是登陆。但是如果为其添加了其他业务，比如同时返回了用户信息。 接口的描述就变为—— 登陆并获取用户信息。 我觉得这种改变，就违背了所谓的“简单”。 “简单”，需要让所有的微服务以及接口更加纯粹。 我有理由相信，微服务还会进一步细分，进一步拆分。 拆到最后，一个微服务可能就是一个接口，底层可能就是一句SQL。

分布式架构，分布式系统，软件架构风格，这些名词就像一条条小蛇一样，在我脑子钻来钻去。尤其是软件架构风格，什么数据流风格，返回调用风格，管道风格，虚拟机风格，仓库风格，说是系统组织形式的惯用模式。都这么说应该很重要吧，然而我觉得他就是一个分类而已。但到分布式架构这么，又合到一块儿了，那那都能挨的上。

我对简单的理解 1. 接口的职责明确，尽量不要有多重含义 2. 接口与实现之间是插拔式、可扩展的

“简单”是多种角度取舍后的结果 直观的看，就是大与小、多与少、繁与简的变化 从维护模块数量的角度来看，模块粒度变小更简单，模块数量依赖关系更复杂 从模块提供的能力及职责角度来看，模块职责更单一清晰，依赖的模块也更灵活 总的来说微服务优势更突显于劣势 模块与模块的关系，就如同岗位和职责，不同的人负责不同岗位，干不同的事，岗位与岗位之间难免会有交集，但更多的时候还是各司其职，当有变动时，执行安排新岗位划分新职责即可

🤔☕️🤔☕️🤔 有了接口，就可以单独实现，啥都要联合调试，必死 有了简单，就可以后续维护，看不懂不敢修改，必死

简单分为两个方面，对于微服务个体，软件系统模块抽象成服务，模块与模块直接的调用抽象成服务与服务之间的通信，保持通信接口的简单。然而对于整体而言，微服务并不是划分的越多越好，而是恰到好处，方便微服务系统的服务治理。

“简单”主要是接口定义的准确，在实现上明确，不牵扯其他业务需求，方便后续的需求的组合和准确定位修改，说白了就是易扩展、灵活度高