微服务的一些概念

什么是微服务

1：很小，专注于做好一件事
随着新功能的增加，代码库会越变越大。时间久了代码库就会非常庞大，以至于想要知道该在什么地方做修改都很困难。尽管我们想在巨大的代码库中做到清晰地模块化，但事实上这些模块之间的界限很难维护。相似的功能代码开始在代码库中随处可见，使得修复bug或实现更加困难。

在一个单块系统中，通常会创建一些抽象层或者模块来保证代码库的内聚性，从而避免上述问题。内聚性是指将相关代码放在一起。在考虑使用微服务的时候，内聚性这一概念很重要。

疑问
服务应该多小？关键因素是该服务是否能够很好地与团队结构相匹配。如果代码库过大，一个小团队无法正常维护，那么显然应该将其拆成小的。

2：自治性
一个微服务就是一个独立的实体。它可以独立的部署在PAAS上，也可以作为一个操作系统进程存在。我们要尽量避免把多个服务部署在同一台机器上。

服务之间均通过网络调用进行通信，从而加强了服务之间的隔离性，避免紧耦合。

这些服务应该可以彼此间独立进行修改，并且某一个服务的部署不应该引起该服务消费方的变动。对于一个服务来说，我们需要考虑的是，什么应该暴露。什么该隐藏。如果暴露的过多，那么服务消费方会与该服务的内部实现产生耦合。这会使得服务和消费方之间产生额外的协调工作，从而降低服务的自治性。

服务会暴露出API，然后服务之间通过API通信。API的实现技术应该避免与消费方耦合，这就意味着应该选择与具体技术不相关的API实现方式，以保证技术的选择不被限制。

主要的好处

1：技术异构性
在一个由多个服务相互协作的系统中，可以在不同的服务中使用最适合该服务的技术。尝试使用一种适合所有场景的标准化技术，会使得所有的场景都无法得到很好的支持。

如果系统中的一部分需要做性能提升，可以使用性能更好的技术栈重新构建该部分。系统中不同部分也可使用不同的数据存储技术。

2：弹性
弹性工程学的一个关键概念是舱壁。如果系统中的一个组件不可用了，但并没有导致级联故障，那么系统的其他部分还可以正常运行。服务边界就是一个很显然的舱壁。在单块系统中，如果服务不可用，那么所有的功能都会不可用。对于单块服务的系统而言，可以通过将同样的实例运行在不同的机器上来降低功能完全不可用的概率，然而微服务系统本身就能够很好地处理服务不可用和功能降级问题。

3：扩展
庞大的单块服务职能作为一个整体进行扩展。即使系统中只有一小部分存在性能问题，也需要对整个服务进行扩展。如果使用较小的多个服务，则可以只对需要扩展的服务进行扩展，这样就可以把那些不需要扩展的服务运行在更小的、性能稍差的硬件上。

4：简化部署
在有几百万行代码的单块应用程序中，即使只修改了一行代码，也需要重新部署整个应用程序才能够发布该变更。这种部署的影响很大、风险很高，因此相关干系人不敢轻易做部署。于是在实际操作中，部署的频率就会变得很低。这意味着在两次发布之间对我们的软件做了很多的功能增强，但直到最后一次才把这些大量的变更一次性发布到生产环境中。这时，另外一个问题就呈现出来了：两次发布之间的差异越大，出错的可能性越大

在微服务架构中，各个服务部署是独立的，这样就可以更快地对特定部分的代码进行部署。如果真出了问题，也只会影响一个服务，并且很容易快速回滚，这也意味着客户可以更快地使用我们开发的新功能。

5：与组织架构相匹配
微服务架构可以很好地将架构与组织架构相匹配，避免出现过大的代码库，从而获得理想的团队大小及生产力。服务的所有权也可以在团队之间迁移，从而避免异地团队的出现。

6：可组合性
分布式系统和面向服务架构声称的主要好处是易于重用已有功能。而在微服务架构中，根据不同的目的，人们可以通过不同的方式使用同一个功能，在考虑客户如何使用该软件时这一点尤其重要。

在微服务架构中，系统会开放很多接口供外部使用。当情况发生改变时，可以使用不同的方式构建应用，而整体化应用程序只能提供一个非常粗颗度的接口供外部使用。

7：对可替代性的优化
如果你在一个大中型组织工作。很可能接触过一些庞大而丑陋的遗留系统。这些系统无人敢碰，缺对公司业务的运营至关重要。为什么这些系统到现在还没有被取代？主要是因为工作量很大、而且风险很高。

当使用多个小规模服务时，重新实现某一个服务或者是直接删除该服务都是相对可操作的。使用微服务架构的团队可以在需要时轻易的重写服务，或者删除不再使用的服务。当一个代码库只有几百行时，人们也不会对它有太多感情上的依赖，所以很容易替换它。

面向服务的架构

SOA(面向服务的架构)是一种设计方法，其中包含多个服务，而服务之间通过配合最终会提供一系列功能。一个服务通常以独立的形式存在于操作系统进程中。服务之间通过网络调用，而非采用进程内调用的方式进行通信。

人们逐渐认识到SOA可以用来对应臃肿的单块应用程序，从而提高软件的可重用性，比如多个终端用户应用程序可以共享同一个服务。它的目标是在不影响其他任何人的情况下透明地替换一个服务，只要替换之后的服务的外部接口没有太大的变化即可。这种性质能够大大简化软件维护甚至是软件重新的过程。

SOA本身是一个很好的想法，但尽管做了很多的尝试，人们还是无法在如何做好SOA这件事上达成共识。

实施SOA时会遇到这些问题：通信协议(SOAP)如何选择、第三方中间件如何选择、服务粒度如何确定等。

在现实世界中，由于我们对项目的系统和架构有着更好的理解，所以能够更好地实施SOA，而这事实上就是微服务架构。

其他分解技术

当你开始使用微服务时会发现，很多基于微服务的架构主要有两个优势：首先它具有较小的粒度，其次它能够在解决问题的方法上给予你更多的选择。那么对于其他的技术是否也有相应的好处呢？

1：共享库
基本上所有的语言都支持将整个代码库分解成多个库，这是一种非常标准的分解技术，这些库可以由第三方或者自己的组织提供。

优点：团队可以围绕库来进行组织，而库本身可以重用

缺点：首先，无法选择异构的技术。一般来讲，这些库只能在同一种语言中，或者至少在同一个平台上使用。其次，会失去独立地对系统某一部分进行扩展的能力。再次，除非你使用的是动态链接库，否则某次当库有更新的时候，你需要重新部署。

共享库确实有其相应的场景。服务之间可以并且应该大量使用第三方库来重用公共代码，但有时候效果不太好。

2：模块
除了简单的库之外，有些语言提供了自己的模块分解技术。它们允许对模块进行生命周期管理，这样就可以把模块部署到运行的进程中，并且可以在不停止整个进程的前提下对某个模块进行修改。

尽管在一个单块进程中创建隔离性很好的模块是可能的，但是我很少见到真正有人能做到。这些模块会迅速和其他代码耦合在一起，从而失去意义。而进程边界的存在则能够有效地避免这种情况的发生。

除了把系统划分为不同的服务之外，你可能也想要在一个进程内部使用模块进行划分，但是仅仅使用模块划分不能解决所有的问题。

没有银弹

微服务不是免费的午餐，更不是银弹，如果你想要得到一条通用准则，那么微服务是一个错误的选择。你需要面对分布式系统需要面对的复杂性。

每个公司、组织及系统都不一样。微服务是否适合你，或者说你能够在多大程度上采用微服务，取决于很多因素。

&<微服务设计>