微服务的由来

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

领域驱动设计(DDD)

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

持续交付

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

按需虚拟化

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

基础设施自动化

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

小型的自治团队

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

什么是微服务

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

小，专注于一件事

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

---

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

自治

这是微服务的优点，也一定程度上导致了微服务的复杂性。 自治，代表每个服务是独立个体，所以我们可以*的进行技术选型，服务之间通信用语言无关的api进行网络通信。也是因为自治，所以我们要保证每个服务能够独立的升级部署而不会对消费者产生影响，避免一个问题出现导致整个系统功能不可用的情况。

协同

虽然我们是一系列不同的个体，但是我们还是一个整体，所以就需要我们各个服务之间有交互有通信，并且需要用某些技术来解决分布式带来的新的问题。

微服务的好处

微服务是分布式的，所以具有分布式的所有好处，而且明确定义了界限上下文，也带来了更多的好处。

• 技术异构
• 弹性好（处理服务不可用和功能降级）
• 扩展方便，成本低
• 简化部署
• 与组织结构相匹配
• 可组合 易于重用完整的功能
• 对技术替代性的优化

微服务的缺点

当然微服务不是银弹，不是整个软件行业的终极解决方案，总是会存在不可忽视的缺点。同样大部分的缺点也是分布式带来的

• 性能（内存处理转化为远程调用）
• 可靠性 （远程调用失败的可能性）
• 最终一致性
• 操作的复杂性

因为还没有在实际中使用过微服务，但是对分布式还是有不少实践，所以结合一些书籍，写下了这篇文章做了一下总结。