.Net Core微服务系列--理论篇

微服务的由来

微服务最早由Martin Fowler与James Lewis于2014年共同提出来的，但是微服务也不是一个全新的概念，它是由一系列在实践中获得成功并流行起来的概念中总结出来的一种模式，一种概念。而这一系列的概念大体上有这些:
领域驱动设计(DDD),持续交付，按需虚拟化，基础设施自动化，小型的自治团队，大型集群系统。

领域驱动设计(DDD)

DDD中我们关心了三个概念：领域建模，限界上下文，职责。这三个概念能很好的帮我们在微服务中按照业务分割出足够小且高内聚低耦合的服务，这也是Evans 在《领域驱动设计》一书中的比喻 “细胞之所以会存在，是因为细胞膜定义了什么在细胞内，什么在细胞外，并且确定了什么物质可以通过细胞膜”，我们每个服务都应该是有自己的职责或者可以说要满足单一原则，要尽量保证内聚，并且要定义好与外部的交互。

持续交付

以往也包括现在的很多公司，生产环境的发布几乎总是痛苦的事情，凌晨或者周末加班加点进行发布而且很可能一出问题就是全部回滚到上一个版本。但是现在，因为实行了持续交付，团队在一天内都可能在生产环境发布很多次。
持续集成，持续交付已经是现代软件很重要的一个特性，对软件产业产生了深远的影响，当然这一特性也跟微服务紧密的结合在一起了。当然单体架构在持续交付方面的问题太显著了，但是微服务在这一方面确实优势明显。微服务系统设计开始就是拆分为独立自治的一些服务的集合，每次的持续交付我们只需要关注某个或者某些微服务的交付，从而在很大程度上减少了持续交付的工作量和风险。当然这就要保证各个服务之间的低耦合，在一个服务更改的时候不会带消费方带来影响。

按需虚拟化

系统在高并发的时候总是会遇到性能瓶颈，但是瓶颈一般不是存在在整个系统而是在某几个特有的模块比如说订单，也不是说会一直存在瓶颈比如双11。所以按需进行扩展是必要解决的问题。而对于微服务，我们借助虚拟化平台，可以单独的为某个服务按需创造机器并调整大小。

基础设施自动化

这个其实跟按需虚拟化可以一起的，当我们需要水平扩展的时候，不可能为每次创造的机器进行一番部署，所以我们需要基础设施的自动化来帮组我们完成方便快捷的扩展

小型的自治团队

自治团队，可以对应到自治服务。一个独立的服务，可以语言自由，架构自由，集成自由，部署自由，我们只需要保证团队做出来的东西满足一定的条件就可以完全作为一个独立的单元来进行开发管理维护。

什么是微服务

微服务就是一些协同工作的小而自治的服务。

小，专注于一件事

这个就是我们常常说的职责单一。

在我的职业生涯中，不乏会接手其他人的项目，每每总是会抱怨这个项目代码量太多了，业务逻辑太分散，常常有牵一发而动全身的时候。而微服务则是把职责单一原则应用到服务上，根据业务来划分限界上下文，进而划分出不同的服务，这样每个服务都只用关注到某个限界上下文中，从而很大程度上避免了代码库过大而难以维护的问题。