微服务概念

来自于《微服务设计》的读书笔记。

1、什么是微服务

作为一名有经验的技术人员，相信我们在日常的开发过程中、或者是技术交流的过程中，是很容易听见微服务这个名词的，但是什么是微服务呢？这个概念如果不清楚，对于我们后面使用 DDD 来做服务拆分也是很有难度的。

1.1、职责单一

单体系统中我们所有的业务代码都是在一起的，就会导致一个项目下面的代码膨胀，哪个地方一旦出现了 BUG 可能会导致很多地方的一个业务错误，而这个时候如果我们想要进行代码的修复，也是一件很闹心的事情，因为代码之间的耦合程度太高了。

在学习设计模式的时候会介绍几大原则，而其中的一条就是单一职责原则（讲究模块功能要尽可能的独立），微服务就很好的践行这个原则，根据业务的边界来确定服务的边界，这样就很容易的确定某个功能代码应该放在哪里。

而想要保证一个服务的内聚高，那么所有的代码都会为当前模块服务，这也就意味着代码量不会很大，要将一些不太相关的量剔出来成为三方。但是什么样的代码量叫做小呢，多小才合适呢，可能没有一个标准答案，但和扇入扇出要平衡一样，不能太小功能不齐全，不能太大内聚降低。

1.2、自治性

之前我们讲到微服务就是一个小型的独立系统，可以单独的部署出来，一个服务内部的变动是可以独立修改的。相对于外界而言使用 API 接口进行通信，以实现技术和消费方之间的解耦合。

也可以这样的来理解，就是一个功能单一的服务提供者，保持高度的内聚为其他服务提供访问能力，自身对外界的依赖较小，在发生变化时对外界是屏蔽的，即使是更新出现 BUG 也能快速的回滚到之前版本而不影响其他服务的正常工作。

而对于一个系统的耦合程度有一个黄金法则：

• 你能否修改一个服务并对其进行部署，而不影响其他的任何服务？
• 而要达到上面的这个目的，需要正确的进行建模服务和 API 搭建。

2、微服务的好处

微服务就是专门适应于当前的分布式环境的，其好处适合于任何一个分布式系统。但相对于一般的分布式系统，微服务有着更加紧致的表现。

2.1、技术异构性

每个服务之间的相对隔离的，也就是彼此之间的实现不用相同，可以使用最适合于当前服务场景下的技术来进行服务的开发，以达到最优的方案解，特别是在系统中的一部分需要进行性能升级时，可以使用更好的技术栈来进行重构。

可以帮助我们更快的采用新技术，并且理解这些技术的好处。这个点可能在传统中看来是不太现实的，因为一个稳定的系统相对于一个使用新技术的系统来说是更加重要的，如果在采用新技术重构的过程中造成一些不兼容的问题将是致命的打击。而微服务本身的体量就很小，一个在重构的过程中发生了意想不到的问题之后也可以快速的回滚到之前的稳定的版本，而不用担心会对其他服务的正常工作产生影响（而在这个过程中出现的一系列的问题对于企业今后进行更改好的性能优化是有很大的借鉴意义的）。

不过同时使用多种技术对于企业来说维护成本是很巨大的，每个技术都需要有一个专业的负责人保障系统运行的可靠性，所以迂回到了微服务划分的体量问题上来了。这里有一个很关键的点就是：

微服务如何寻找平衡？

• 弹性配置

  服务之间需要进行划分，也就是各个不同的服务提供者之间是需要有明显的界限的，这个界限是确保当一个服务发生问题之后不会影响到其他的服务正常工作。

  微服务这种服务隔离的性质能够很好的处理服务不可用带来和功能降级带来的问题，但还是需要谨慎对待，因为分布式下的网络和机器的故障是时常发生的，我们需要理解不同场景下的问题原因以及相对应的解决方案。

• 独立扩展

  在传统的单体项目的配置下，一个服务需要进行拓展时需要将整个系统进行拓展，即使只是一小块的服务存在性能问题。而微服务是一个单独的服务，只需要针对性的进行拓展即可，这样就能均衡的分配物理设备在不同重要程度的服务中去，以达到最大的性能比例。

• 简化部署

  一个体谅在几百万行代码量的系统需要进行一次的改版发布是非常苦难的，即使你的变动很小，你也需要将整个项目进行重新部署，而一旦修改产生 BUG 将会是一个很大的麻烦，所以风险很高。

  而微服务的隔离性使他在这方面占据优势，体量小发板块，而且即使发生错误，也能够很快的回滚到之前的稳定版本而不会对当前正在服务的其他程序造成很大的影响。

2.2、软特性

上面谈到几乎都是微服务自身所展现出来的好处，我们还需要知道他和其他组件进行交互时的匹配程度。

• 组织结构匹配

  毫无疑问在小代码库中工作的小团队的工作是更加高效的，微服务架构能很好地将架构和组织结构相匹配，从而获得理想的团队大小和生产力。

• 可组合性

  目前需要的应用程序种类是很多的，而避免重复开发的方式就是对已有服务的一个重用，微服务通过暴露 API 的这种方式能够很好的和其他系统完成整合。

• 可替代性的优化

  微服务的体谅很小，大多数情况只有几百行而已，相信大家作为一个有经验的开发人员是新这样的业务也不是很难，也就没有多大的依赖性，能够很容易的进行替换。

3、其他的分解技术

微服务是对于整体服务的一个分解结果，本身具有更小的粒度，其次它能够在解决问题的方法上给予你更多选择，那其他的分解技术的实现是不是也有相同的好处呢？

3.1、共享库

在我们的日常工作中会有很多的重复工作需要实现，比如一般的序列化工作类这些，而我们常常的做法就是将其尽心抽离出来形成一个统一的工具类，以供我们在开发的过程中进行快速的使用。

基于此，不同的团队就可以通过库的形式来共享共享功能，团队也可以围绕库来进行组织，而库本身就可以进行重用，但这里会有一个问题。

• 一是语言限制

  我们所使用的工具类大多数都只能在我们自己的开发体系中进行使用，就像目前团队使用的是 Java ，那么大概率的工具类都是该语言进行编写的，其他的语言环境中想要进行使用还是比较麻烦的，或许我们可以抽象出来在当前平台所共享的一个工具类。

• 二是无法异构

  如果一个底层的通用代码实现被更改，那么所有线上的项目都将会因为没有接收到其最新的实现而进行暂停重新部署（除非使用的是动态链接库这样的技术，那么就只能重新部署了），无法进行独立的变更修改。

• 三是耦合增加

  一个底层的代码库被很多的服务所共享引用的话，抽离出来会降低我们的工作量，但是要小心他成为了一个耦合点。

3.2、模块

除开库的形式外，例如 Java 就实现了模块式的分解技术，允许对模块进行生命周期的管理来达到动态的模块修改操作。也就是我们常常听见的 OSGI（开放服务网关协议） 技术，不过该技术原本不是 Java 支持的，所有需要在靠后一点的 JDK 中才能看见他的使用。

Erlang 采用了不同方式，模块的概念直接嵌入到语言的运行中，这种模块化分解的方式是很成熟的，因此可以更加优雅的支持模块的升级。

虽然模块化的功能非常的惊人，但是还是会存在和共享库类似的缺点，他会限制我们使用新技术和独立对服务进行拓展的能力，而且有可能会导致过度耦合的集成技术，同时也缺乏响应的接缝来进行架构的安全性保护。