什么是微服务？

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

一、微服务第一个特性在于“小”

只需要专注做好一件事情，Martin的单一职责原则（Single Responsibility Principle）的论述：把因相同原因而变化的东西聚合到一起，把因不同原因而变化的东西分离开来。这很好的强调了内聚性这一概念。

那么，代码库多小才算小？

代码行衡量代码库的多少是行不通的，因为有些语言表达力强，区区几行代码就道尽了程序员的意图，即代码密度高。

一个比较老套的说法：足够小即可，不要过小。当你不再感觉你的代码库过大，可能它就足够小了。

另一个回答服务应该多小的关键因素是，该服务的大小是否能很好的匹配团队结构，如果一个小团队不能很好的维护该服务，可能服务还可以再拆分为更小的。

二、自治性

微服务的第一个特性在于自治性，一个微服务就是一个独立的实体，可以独立部署在PAAS，也可以作为一个操作系统进程存在。

自治性对应的是耦合性低，有一个黄金法则：如果能修改一个服务并部署，而不会影响其他任何服务，那么系统就很好的解耦了。

三、微服务的主要好处

1. 技术的异构性

每个微服务可以各自使用不同的技术栈，包括但不限于编程语言、数据库，这使得不同微服务能选用最合适的技术栈来实现，大大提高了灵活性。

 2. 弹性

假如一个微服务不可用了，其他微服务还能正常使用，这是因为微服务之间是隔离的。

每个微服务都运行在多台机器上，确保可用性，进行弹性伸缩，保证高峰和低谷时的访问需求和运维成本。

3. 扩展

对于单体服务而言，假设某个组件有性能问题需要升级，那整个服务都需要升级到下一个版本。

而对于微服务而言，某个微服务有性能问题，只需要升级该微服务，而不影响其他微服务的正常运行。

4. 简化部署

对于单体服务，即使变更了一行代码，也需要部署整个应用程序，由于单体服务体积庞大，构建部署都会比较耗时，因此，开发者在两次发布之间往往会有很多功能增强，这意味着一次要发布大量的变更到生产环境，而发布的新代码行数越多，出错的概率也越大。

微服务就把问题简化了，变更一行代码只需要发布一个微服务相关的一批机器，而发布大量代码时，即使出了问题，也可以快速回滚一个微服务。

5. 与组织架构相匹配

一个团队负责维护若干微服务。

6. 可组合性

微服务能很大程度保证重用已有的功能。

7. 对可替代性的优化

假如有一个代码量庞大的（数百万行代码）、使用古老的Fortran语言变体写的遗留系统，需要重写，这时候采用微服务的方式替代，也是一个不错的方案。

四、没有银弹

No Free Lunch Principle原则说明了，任何新鲜事物带来好处的同时，也会有相应的代价，微服务也不例外，在带来上述好处的同时，微服务也存在缺点，那就是微服务之间的调用关系变得异常负杂，这也在提醒我们，拆分微服务时也不能过小，过小则微服务数量巨多，关系也就更加复杂了。