微服务架构定义
微服务架构是一种架构风格和架构思想，它倡导我们在传统软件应用架构的基础上，将系统业务按照功能拆分为更加细粒度的服务，所拆分的每一个服务都是一个独立的应用，这些应用对外提供公共的API，可以独立承担对外服务的职责，通过此种思想方式所开发的软件服务实体就是“微服务”，而围绕着微服务思想构建的一系列体系结构(包括开发、测试、部署等)，我们可以将它称之为“微服务架构”。
根据微服务架构的定义，将传统单体架构拆分为微服务架构的方式如图1-4所示。
图1-4传统单体架构拆分为微服务架构
从图1-4中可以看出，微服务架构已将传统单体架构中的订单服务、商品服务和用户服务拆分为了独立的服务，其中的每一个服务都是一个独立的应用，可以访问自己的数据库，这些服务对外提供公共的API，并且服务之间可以相互调用。
注意：微服务和微服务架构是两个不同的概念。微服务强调的是服务的大小，它关注的是某一个点，而微服务架构是一种架构思想，需要从整体上对软件系统进行全面的考虑。
微服务架构的优点
与传统单体应用架构相比，微服务架构有很多优点，具体表现如下：
1.复杂度可控
微服务架构在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰地表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性，并提高了开发效率。
2.可独立部署
由于微服务具备独立的运行进程，所以每个微服务都可以独立部署。当某个微服务发生变更时，无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低了对生产环境所造成的风险，最终缩短应用交付周期。
3.技术选型灵活
微服务架构下，技术的选型是多样化的。每个团队都可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术。由于每个微服务相对简单，当需要对技术进行升级时，所面临的风险较低，甚至完全重构一个微服务也是可行并容易的。
4.易于容错
当架构中的某一组件发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，导致整个应用不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。
5.易于扩展
单个服务应用也可以实现横向扩展，这种扩展可以通过将整个应用完整的复制到不同的节点中实现。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。
6.功能特定
每个微服务有自己的业务逻辑和适配器，并且一个微服务一般只完成某个特定的功能，例如商品服务只管理商品、客户服务只管理客户等。这样开发人员可以完全的专注于某一个特定功能的开发，而不用过多的考虑其他，从而提高开发效率。
除了上述几点好处外，微服务架构还有很多好处，由于篇幅有限，这里就不一一列举了，但从微服务架构的好处可以看出，使用微服务可以很好的解决传统单体架构中的问题。
微服务架构的不足
微服务架构除了有上面所讲的各种优点外，还存在着一些不足，这些不足的具体表现如下：
1.开发人员必须处理创建分布式系统的复杂性
①开发工具(或IDE)是面向构建传统的单体应用程序的，不为开发分布式应用程序提供全面功能上的支持。
②测试更加困难。在微服务架构中，服务数量众多，每个服务都是独立的业务单元，服务主要通过接口进行交互，如何保证依赖的正常，是测试面临的主要挑战。
③开发人员必须实现服务间的通信机制。
④实现用例跨多个服务时，需要面对使用分布式事务管理的困难。
⑤l实现跨多个服务的用例，需要团队之间进行仔细的协调。
2.部署的复杂性
在部署和管理时，由许多不同服务类型组成的系统的操作比较复杂，这将要求开发、测试及运维人员有相应的技术水平。
3.增加内存消耗
微服务架构用多个服务实例取代了1个单体应用程序实例，如果每个服务都运行在自己的JVM中，那么有多少个服务实例，就会有多少个实例在运行时的内存开销。
微服务架构与SOA的区别
通过前3个小节的学习，相信有些读者对微服务架构已经有了一定的了解。在学完后，细心的读者可能会有这样一个疑问，微服务架构与SOA都是对单体架构的拆分，那么他们有什么不同呢?下面通过一个表格对两者的区别进行对比，如表1-1所示。
表1-1微服务架构与SOA的区别
史上最全面微服务教程：SpringCloud+Elasticsearch+分布式系统
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/254066.html