一 什么是微服务
微服务就是一些协同工作的小而自治的服务
很小，专注于做好一件事
在单一模块系统中，随着新功能的增加，代码库会越来越大。时间久了代码库会变得非常庞大，以至于在什么地方修改都很困难。尽管有时候在巨大的项目中做到了清晰的模块化，但事实上这些模块之间的界限很难维护。相似的代码随处可见，使得修复bug或实现新功能更加困难。
我们在开发某个功能时的一个指导原则是“高内聚，低耦合”，微服务是将这一理念应用在独立的服务上。根据业务边界来确定服务的边界，这样就很容易确定某一功能代码该放在哪里。由于服务专注于某个边界之内，因此，可以很好地避免由于代码量过大而衍生出的各种问题。
一个微服务多小合适呢？这个没有统一的标准。按业务功能拆分也可，可以足够小，但不能太小。也可以根据团队的组织结构进行相匹配，一个团队五到十人。
自治性
- 一个微服务就是一个单独的尸体。它可以单独低部署在PAAS上，也可以作为一个单独的操作系统进程存在。
- 这些服务之间是通过网络调用进行通信的，从而加强了服务之间的隔离性，避免紧耦合。
- 微服务可以彼此单独进行修改，并且某个服务的部署不应该引起该服务的消费方的变动。
- 服务暴露的API的实现技术应该避免与消费方耦合。
二 微服务的主要好处
微服务有很多不同的好处，其中很多好处也适用于任何一个分布式系统。但相对于分布式系统或者面向服务的架构而言，微服务更胜一筹，它会把好处推向极致。
技术异构性
在一个有多个服务相互协作的系统中，可以在不同的服务中使用最适合该服务的技术。如果系统中的一部分需要做性能提升，可以使用性能更好的技术栈重新构建该部分。比如在社交网络系统中，可以使用图数据库处理用户之间的交互操作，文档数据库处理用户发的帖子。
弹性
在单块系统中，如果服务不可用，那么所有的功能都会不可用。虽然单块系统可以通过将相同的实例运行在不同的机器上来降低功能的完全不可用的概率，然而微服务本身就能很好地处理服务不可用和功能降级的问题。
微服务系统虽然可以改进弹性，但是也必须谨慎对待，因为一旦使用了分布式系统，网络就会是个问题。
扩展
庞大的单块服务只能作为一个整体进行扩展。即使系统中只有一小部分存在性能问题，也需要对整个服务进行扩展。如果使用较小的多个服务，则可以对只需要扩展的服务进行扩展，这样可以把不需要扩展的服务运行在更小，性能较差的硬件上。
简化部署
在有着几百万行代码的单块服务应用中，即使修改一行代码，也需要重新部署整个应用，这种部署的影响很大、风险很高。往往为了减少部署频率，一般都是做了很大改动后在进行异常部署。这样就带了另一个问题，两次发布之间的差异越大，出错的可能性就更大！
在微服务架构中，各个服务的部署是独立的，这样就可以更快地对特定部分的代码进行部署。万一出了问题，也只是影响一个服务，并且容易快速回滚。
与组织结构相匹配
在项目开发中，团队和代码过大很容易引起这样那样的问题。当团队是分布式的时候，问题更明显。微服务架构可以很好地将架构和组织结构相匹配，避免出现大量的代码库，从而获得理想的团队大小及生产力。
可组合性
在微服务架构中，系统会开放很多接口供外部使用。当情况发生改变是，可以使用不同的方式构建应用。
可替代性
我们经常在公司遇到维护旧系统的情况，一个庞大而丑陋的遗留系统，无人敢碰，更不敢重构，唯一的原因就是 工作量太大，并且风险极高。但是在微服务架构中，由于每个服务功能单一，并且代码量也很小，重新实现某个服务或者直接删除该服务都相对可操作。
三 没有银弹
微服务不是免费的午餐，更不是银弹，如果你想要得到一条通用准则，那么微服务是一个错误的选择。
每个公司、组织及系统都不一样。微服务是否适合你，或者说你能够多大程度上使用微服务，取决于很多因素。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
