微服务设计第一章

1.什么是微服务

简单而言微服务就是一些协同工作的小而自治的服务。这与传统服务存在一些不同的点。

1.1 很小，专注于做好一件事情

随着新功能的增加，代码库会越变越大。时间久了代码库会非常庞大，以至于想要知道在什么地方做修改都很困难。尽管我们想在巨大的代码库中做到清晰的模块化，但事实上这些模块之间的界限很难维护。相似的功能代码开始在代码库中随处可见，使得修复bug或实现更加困难。
在一个单块系统内，通常会创建一些抽象层或者模块来保证代码的内聚性，从而避免上述问题。内聚性是指将相关代码放一起，在考虑使用微服务的时候，内聚性这一概念很重要。
微服务将单一职责的理念应用在独立的服务上，根据业务的边界来确定服务的边界，这样很容易确定某个功能代码应该放在哪里。而且由于该服务专注于某个边界之内，因此可以更好地避免由于代码库过大衍生出的很多相关问题。

1.2 自治性

一个微服务就是一个独立的实体。它可以独立地部署在PAAS上，也可以作为一个操作系统进程存在。
服务之间通过网络调用进行通信，从而加强了服务之间的隔离性，避免紧耦合。
这些服务应该可以彼此间独立修改，并且一个服务的部署不应该引起消费方的变动。

2.主要好处

微服务有很多不同的好处，其中很多好处也适用于任何一个分布式系统。

2.1 技术异构性

在一个有多个服务相互协作的系统中，可以在不同的服务中使用最合适该服务的技术，尝试使用一种适合所有场景的标准化技术，会使得所有场景都无法得到很好的支持。
如果系统中的一部分需要做性能提升，可以使用性能更好的技术栈重新构建该部分，系统中的不同部分也可以使用不同的数据存储技术，比如对于社交网络来说，图数据库能更好地处理用户之间的交互操作，但是对于用户发布的帖子而言文档数据库可能是一个更好的选择。
微服务可以帮助我们更快的采用新技术，并且理解这些新技术的好处。尝试新技术通常伴随着风险，尤其是对于单个系统而言，对于微服务而言，总会存在一些地方让我可以尝试新技术。

2.2 弹性

如果系统中的某一个组件不可用了，但并没有导致级联故障，那么系统的其它部分还可以正常运行。单个系统中如果服务不可用，那么所有的功能都不可用。微服务系统可以很好地处理服务不可用和功能降级问题。

2.3 扩展

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

2.4 简化部署

在有几百万代码行的单块应用中，即使只修改了一行代码，也需要重新部署整个应用程序才能够发布变更。这种部署的影响很大、风险很高，因此相关干系人不敢轻易做部署。于是在实际操作中，部署的频率就会变得很低。
在微服务架构中，各个服务是独立部署的，这样也就可以更快地对特定部分的代码进行部署。如果真的出了问题，也只会影响一个服务，并且能够进行快速回滚。

2.5 与组织结构相匹配

微服务架构可以很好地将架构与组织结构想匹配，避免出现过大的代码库，从而获得理想的团队大小和生产力。

2.6 可组合性

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

2.7 对可替代性的优化

单个微服务的代码量较少，重新实现某一个服务或者是直接删除该服务都是相对可操作的。使用微服务架构的团队可以在需要时轻易的重写服务，或者删除不在使用的服务。

结语:没有银弹

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