微服务已经火了有一段时间了，Martin Fowler 在2014年3月也开始发文对微服务进行说明和分析，近两年各种技术社区内对微服务的分享和讨论也比比皆是。和其他技术话题一样，争议总是不少的，有争议说明大家都在思考，所以我也参与到大部队中来，一边学习一边谈谈我的理解。

什么是微服务

我理解微服务实际上是SOA的一种实现方式，它并不是什么新东西，也不是什么发明创造，只是在近几年随着虚拟化技术、基础设施自动化、分布式系统、持续集成、领域驱动设计等的大量实践应运而生的一种模式，只因这些技术实践相结合让人们重新思考在软件产品交付过程中如何做到更快、更灵活，并拥抱变化，从而总结出了微服务的架构风格。

微服务特点

既然有个“微”字，那么很多人就会觉得代码少就是微服务，但实际上“微”和代码量并没有直接关系。这里的“微”更应该理解为专注，或者说高内聚，一个微服务只专注于一种业务，遵循单一职责原则，不要为了小而小，要根据实际业务来找出服务边界。

除了“专注”，微服务另一个主要特点就是高度自治，首先服务架构要和团队结构相匹配，此外服务间是低耦合的，服务间通过网络进行API调用，服务隐藏内部实现，修改一个服务不会对其他服务带来影响，在这些前提下，团队可以灵活构建服务，并更快响应不断变化的需求。

微服务与单块应用架构比较

先说说开发方面。单块应用意味着采用单一的技术栈，很难对新技术进行尝试，且随着时间的推进，单块应用会变得十分臃肿和复杂，很难保证一个人修改的代码不影响到其他人的代码，且开发者会对修改一些早期的代码望而却步，生怕自己的修改对整个系统造成影响。但是单块应用也正因为采用单一技术栈，使得团队在具体技术层面容易有基本一致的认识，且因为对这一技术栈的了解和深入，开发者就能够更自信的做出稳定的程序。微服务由于服务间的高内聚低耦合及其自治性，每个服务是可以独立演进的，所以团队更容易尝试各种新技术，也更容易对服务进行修改或重构，甚至可以对历史遗留的代码或服务直接进行替换，因为代价很小，且对整个系统带来影响是可控的，因此就使得团队的创新和成长能力更加突出。

测试、部署和监控。单块应用所有代码都是放在一起的，工程中可能有分模块也可能没有，当开发者提交代码后，CD 系统跑完所有测试，再对整个工程进行构建和部署，整个流程的配置相对比较简单，监控需要的一些指标通常运行环境的各种中间件也已经提供了相应的接口，应用中需要做的事情并不多。但是在大型的单块应用中，即使只修改了一行代码，也需要跑完上述整个流程才能发布此次变更，由于重新发布整个应用带来的影响较大，考虑到风险，应用的发布频率会很低，于是在两次发布之间可能会积累了较多的修改和新特性的增加，使得下一次发布和之前的版本差异很大，出问题的概率也就大大增加。微服务中的服务都是独立的，所以一个服务的发布不会影响其他服务，在发布出现问题的情况下也可以快速回滚，因此Bug修复和新特性增加都可以快速上线。但是由于服务之间存在着依赖关系，要对服务进行测试就需要同时启动其依赖的服务，或者采用一些特殊方式来确保测试能够走通，在部署服务过程中如果出现问题，还需要有服务降级手段来保障系统可用性，在监控方面也要结合服务的运行环境做较多工作，且由于一项业务数据可能流经多个服务，为了达到较好的监控效果还要对调用链进行维护。

然后是伸缩性。单块应用运行起来所有功能都是一个整体，一旦其中一个功能挂掉，可能整个应用就挂掉了，要提高应用可用性，就需要对整个应用进行水平伸缩扩展，例如在其他机器上再运行若干个应用实例，并结合负载均衡等手段。另外就是当应用性能不足也需要做水平伸缩扩展时，也要对整个应用进行扩展，即便性能不足的只是其中某一个功能。虽然单块应用的扩展看起来不那么合理，有点浪费系统资源，但是操作简单，维护成本不高。微服务在伸缩性上能够更灵活的进行扩展，符合去中心化的思想，结合现如今流行的公有云服务，可以随时对需要提高可用性和性能的服务进行扩展，但是由于服务实例的增加，随之带来的是服务管理的复杂度上升。

再说说性能。单块应用大都是进程内调用，性能的消耗一方面是系统外的网络、IO等开销，一方面是高并发的处理，这些可以通过一些主流的技术手段来改进，但是由于单块应用内部的高耦合和复杂性，往往对一处进行优化的同时可能又带来其他处的问题，因此很多大型单块应用的优化重构经常只是不停地有人在说，实际操作起来却举步维艰。微服务由于服务间都是网络调用，很多人会觉得增加了太多网络开销，性能堪忧，确实网络调用不会比进程内调用快，但是由于微服务易于重构和创新，因此自身的整体性能也易于得到提高，且提高的性能一般远超出网络的性能开销。

除了以上几点之外，微服务还需要处理分布式系统带来的各种复杂问题，甚至要面对分布式事务或CAP相关问题等等，微服务相比单块应用确实解决了很多问题，也带来了一些新的问题，如何平衡和取舍，这就是架构要考虑的问题，我的想法是取长补短，结合自己团队目前的情况，设计符合自己的架构，要知道没有一种放之四海而皆准的架构方案，所以不要觉得别人用着好的模式你就可以直接拿来用，找到适合自己的方法才是架构之道。

本文只是先挖个坑，没什么内容，以后会展开对微服务的思考，欢迎高人或对微服务有兴趣的朋友和我交流。

本文同时发布于我的微信订阅号

无罔