微服务系列笔记之什么是微服务

导语

微服务（Microservice Architecture）是近几年流行的一种架构思想，它的概念没有很明确的指出。ThoughtWorks 公司的首席科学家 Martin Fowler曾经解释过这个概念：微服务架构风格是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储技术。（By 谷歌翻译）

架构演进

为了更好的了解什么是微服务，我们先来看看架构演进的过程

1、单体架构：对于早期的互联网，由于处于萌芽时期，用户量少，因此也就表示互联网的需求还不多，也就导致互联网产品并发量低，往往只需要一台服务器便可以满足用户。现在这种模式已经完全淘汰，原因也很简单，随着互联网的发展，一台服务器已经无法满足日益增长的用户，这种模式下，一旦服务出现了问题，往往需要进行停机才能进行修复，已经无法满足用户体验。
2、垂直架构：这种架构是在单体架构的基础上，以项目为单位进行划分，将一个大项目拆分成一个单体项目，这种架构虽然一定程度上使开发变得容易，被划分的项目不至于无限扩大，但是也带来了诸多问题，如果项目比较大，这些被划分的项目因为全部都集中在一个工程中，项目与项目之间会出现数据冗余，后期扩展成本高，不易维护。而且往往一个服务没有很好的公用性。
3、SOA架构：这种架构是对垂直架构的优化，它将重复公用的功能抽取成工具，提高了系统的重用性，服务之间通过注册中心进行通信，但是由于服务的界限往往不明确，导致系统与服务之间的耦合性增加，往往一个服务的宕机，会牵涉到其它服务，

微服务

微服务便是对SOA架构的进一步优化，实现服务之间的松耦合，微服务架构通过对业务进行划分实现服务的组件化，并且可以独立部署，实现独立测试，使开发人员开发一个服务只专注于该服务。一句话来说微服务就是一些可以协同工作并且拥有自治功能的服务。下面我们来做更多的解释为微服务的概念。

微服务很小

微服务根据业务的边界进行划分，这样做的好处使它只专于业务边界之内的开发，那可能有人会疑问，划分到什么程度才能算小呢？有没有一个标椎？严格来说很难有人能说清，如果你在开发的时候认为某个服务似乎代码库有点大了，维护起来有点麻烦，这个时候或许就该考虑再一次进行划分了，如果你的服务，交给另一个开发人员进行维护时，他可以在一两天之内读懂你的服务，或许这就是一个好的服务了。同时随着微服务划分的越来越小，它的独立性会越来越好，但是对于众多服务的管理也会变得复杂，这是微服务的一个痛点，但是不要担心，如今有很好的的技术可以对这些一个一个的服务进行了管理。

自治性

一个微服务就是一个独立的个体，并且可以独立运行，服务之间通过网络进行通信。这里的自治性，并不仅仅指服务可以自己独立测试，更重要的是服务与服务之间如何更好的降低耦合性，如果你服务在进行修改的同时，会引起另一个服务发生了不好的改变，可以说，这就不是一个好的服务，另外，对于一个服务来说，应该懂得提供的什么接口是可以通过API进行暴露，又有哪些是应该隐藏的，来提高我们服务的安全性，

隔离性

微服务由于进行了业务划分的隔离，服务之间通过组合的方式构建项目，通信的方式通过网络调用，使得服务往往只需要对外暴露提供的API接口，对于调用的一方来说，不需要知道被调用的服务使用了什么技术，这样以来，我们的微服务可以用不同的语言进行开发，你可以让一个风险小最小的服务采用新技术，这样出现了问题也可以很好的处理。因此微服务也实现了技术的异构性，但是需要明白的是，对于一个团队来说，最好统一语言，这样会减少前期的沟通成本。

扩展性

对于单块服务来说，扩展服务，往往需要对整个服务进行扩展，但是微服务不同，对于较多的且很小的微服务，只需要对需要扩展的模块扩展就可以了，因为服务之间相互独立，几乎不会影响到其它服务。最重要的是，我们可以把很多不同的服务，同时部署在很多的机器上，一台机器无法工作时，将有其它可工作的机器代替。

迭代周期短

微服务每一个都可以独立部署，对于开发人员来讲，只负责几个微服务时，升级更加快，对于如今互联网的迅速发展迭代过程，很明显微服务的部署速度顺应了互联网的潮流。

没有银弹

微服务没有任何一条通用的准则，本篇文章也只能介绍微服务的特性，如果你想继续学习，微服务是必不可少要学的，在接下来的文章中，会介绍Go-mico微服务框架的使用，是我在学习这系列时会做的笔记，如果想要持续学习这方面的知识，欢迎在文章末尾关注我。

本文参考：
书籍《微服务设计》
网站了解单体架构，垂直架构，SOA架构和微服务架构的变化历程