什么是微服务？

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

一个项目随着新功能的增加，代码库会越变越大，在拓展和修复上将十分困难。
我们通常会创建一些抽象层或者模快来保护代码的内聚性，从而避免上述问题。内聚性的单一职责原则：把因相同变化的东西聚合在一起，而把因不同原因而变化的东西分离开来。

微服务将这个理念应用在独立的服务上，根据业务的边界确定服务边界。

自治性

一个微服务就是一个独立的实体，我们应尽量把多个服务部署到不同的机器上，可以大大简化分布式系统的构建。

服务之间均通过网络调用通信，即通过暴露API并对API进行调用而通信，从而加强服务之间的隔离性，避免紧耦合。这些服务之间可以彼此独立进行修改，并且某一服务的部署不应该引起该服务消费方的变动。

微服务的优势

技术异构性

不同的服务适合不同的技术栈，微服务可以采取不同的技术去提升性能。如果想在项目中采用新的技术，对于单块系统而言这是一个巨大的风险；对于微服务而言，可以选择一个风险最小的服务采用新技术，即使出现问题也可以处理。

弹性拓展

微服务可以很好的处理服务不可用和功能降级问题。
微服务由多个服务组成，如果对项目的功能进行拓展，秩序对需要拓展的服务进行拓展，不会影响到其他业务的正常运行。

简化部署

对于一个大的单块系统来说，即使只修改几行代码，也需要重新部署整个应用程序才能够发布该变更，这个部署影响很大风险很高，可能会有很多隐藏bug。在微服务架构中，各个服务的部署是独立的，这样可以对特定部分的代码进行部署，如果真的出了问题，也只会影响到一个服务，并且容易快速回滚。这也意味着客户可以更快的对新功能进行尝鲜。

可替代性

当我们相对系统进行升级时，不必太多的考虑修改的代码是否会对整个系统产生影响，这对单块系统来说是不可想象的，即业界俗称的“屎山”。而使用微服务架构的团队可以轻易的删除或重新某项服务而莫得一点感情。

其他的分解技术

共享库和模块

没有银弹

“没有银弹”指没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍。
**
微服务不是免费的午餐，更不是银弹，如果你想要得 到一条通用准则，那么微服务是一个错误的选择。你需要面对所有分布式系统需要面对
的复杂性。如果你过去的经验更多的是关于单块系统，那么为了得到上述那些微服务的好处， 你需要在部署、测试和监控等方面做很多的工作。你还需要考虑如何扩展系统，并且保证它们的弹性。你还需要处理类似分布式事务或者与CAP相关的问题。