转载地址：https://www.toutiao.com/i6503387715482944013/
诸如亚马逊、eBay、Netflix 等公司都已经采用微服务架构（MicroService Architecture），不再构建庞大复杂的单体应用（Monolithic），而是通过微服务架构将应用拆分为一套小且互相关联的服务。
一个微服务一般完成某个特定的功能，比如订单管理、商品管理、客户管理等。每个微服务都是一个微型应用，包括业务逻辑和各种接口。
基于微服务架构的电商系统
微服务通过暴露 API 被别的微服务或者应用客户端所用。在运行时，每个微服务的实例通常是一个云虚拟机或者 Docker 容器。
每个服务也都有自己的数据库，也可以使用符合自己需要的特定类型的数据库，可以是MySQL，也可是MongoDB。
这种架构设计思路马上在国内也得到了争相效仿，从互联网项目到企业级系统，都纷纷开始采用微服务。那么到底要不要使用微服务架构呢？
Chris Richardson是世界著名的软件架构大师，针对微服务写了一系列文章，重点谈了微服务架构的好处与不足。我们不妨听听大师怎么说。
微服务架构模式的好处
微服务架构模式有很多好处。
首先，分解巨大单体应用为多个微服务，解决了单体应用的复杂性问题。每个服务都有一个定义清楚的边界，通过 RPC- 或者消息驱动API与外接沟通，这样单个微服务相比单体应用更容易开发和维护。
其次，微服务架构使得每个服务都可以由专门的开发团队来开发。开发者可以自由选择开发技术，同时也意味着开发者不需要被迫使用旧项目采用的过时技术。即使重写单个微服务也不会太困难，相比重写整个单体应用容易多了。
第三，微服务架构使得每个微服务独立部署，开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度，使得持续化部署成为可能。
最后，微服务架构使得每个服务可以独立扩展。
微服务架构适合按需扩展
微服务架构的不足
但凡事有利就有弊，微服务也不是万能的。
（1）微服务应用是分布式系统，由此会带来固有的复杂性。开发者不得不使用 RPC 或者消息传递，来实现进程间通信；此外，必须要写代码来处理消息传递中速度过慢或者服务不可用等局部失效问题。
（2）另外一个关于微服务的挑战来自于分区的数据库架构，同时更新多个业务主体的事务很普遍。这种事务对于单体式应用来说很容易，因为只有一个数据库。在微服务架构应用中，需要更新不同服务所使用的不同的数据库，从而对开发者提出了更高的要求和挑战。
（3）测试一个基于微服务架构的应用也是很复杂的任务。比如，对于采用流行的 Spring Boot 架构的单体式 web 应用，测试它的 REST API，是很容易的事情。但对于微服务架构，同样的服务测试需要启动与它有关的所有服务。
（4）另外一个挑战在于服务模块间的依赖。应用的升级有可能会波及多个服务模块的修改。在单体应用中，只需要修改相关模块，整合变化，一并部署就好了。微服务架构模式就需要考虑服务间的依赖关系，按照依赖关系依次部署。
（5）部署一个微服务应用也很复杂，一个微服务应用一般由大批服务构成。每个服务都有多个实例，这就形成大量需要配置、部署、扩展和监控的部分。除此之外，还需要完成一个服务发现机制，以用来发现服务的通信地址和端口。
总结
构建复杂的应用非常困难，单体式的架构更适合轻量级的简单应用，微服务架构模式可以用来构建复杂应用。当然，这种架构模型也有自己的缺点和挑战。比如成功部署一个微服务应用需要开发者有足够的控制部署方法，并高度自动化。所以，现在很多云计算服务商也都提供了微服务架构应用的自动化部署和管理解决方案。
