微服务架构，你需要关注的哪些点

今天谈到系统架构模式，很难不联想起微服务架构。企业或组织在系统架构的实践过程中，从最初的单体架构，之后走向 SOA，逐渐分布式之后，最终产生了微服务架构。

 

微服务架构的出现，为应对快速变化的业务需求、冗长的开发周期提供了一种新的解决方案，它以模块化的思维应对快速变化的业务需求，解耦系统之间各个子系统、业务、数据库，甚至开发团队，使用如自动化部署、自动化业务监控预警、调用链监控、容器化，以及敏捷开发等思想加快软件的开发周期，实现更快速、更高质量的交付，成为当下最流行的架构风格之一。

 

微服务架构如此火热，开发者想要了解其相关知识点，可以通过看书、学习各个公司的实践经验，或者请教有经验的专家，要不就去听技术会议分享，同时网上也有很多相关理论与实践总结可以查看。

 

而我们之前通过网站上“高手问答”这一栏目，为大家提供了一个集中式向专家提问的机会，让更多人能够直接面对专家，提升微服务架构相关能力。当期观众提问与专家的回答有许多精彩之处，故整理出此文，以飨读者。

 

Q：微服务架构和传统的 SOA 架构有什么区别？

面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样系统中的服务可以以一种统一和通用的方式进行

 

相同点

• 需要 Registry，实现动态的服务注册发现机制。

• 需要考虑分布式下面的事务一致性，CAP 原则下，两段式提交不能保证性能，事务补偿机制需要考虑。

• 同步调用还是异步消息传递，如何保证消息可靠性？SOA 由 ESB 来集成所有的消息。

• 都需要统一的 Gateway 来汇聚、编排接口，实现统一认证机制，对外提供 APP 使用的 RESTful 接口。

• 同样要关注如何再分布式下定位系统问题，如何做日志跟踪？就像电信领域做了十几年的信令跟踪的功能。

   

差异点

• 是持续集成、持续部署？对于 CI、CD（持续集成、持续部署），这本身和敏捷、DevOps 是交织在一起的，所以更倾向于软件工程的领域而不是微服务技术本身。

• 使用不同的通信协议是不是区别？微服务的标杆通信协议是 RESTful，而传统的 SOA 一般是 SOAP，不过目前来说采用轻量级的 RPC 框架（Dubbo、Thrift、gRPC）非常多，在 Spring Cloud 中也有 Feign 框架将标准 RESTful 转为代码的 API 这种仿 RPC 的行为，这些通信协议不应该是区分微服务架构和 SOA 的核心差别。

• 是流行的基于容器的框架还是虚拟机为主？Docker 虚拟机和物理机都是架构实现的一种方式，不是核心区别。

   

SOA 和微服务的一个主要不同点就是自动化程度上的不同。大部分的 SOA 实现只达到服务级别的抽象，而微服务达到了对实现和运行环境的抽象级别。

 

在一个规范的微服务中，每个微服务应该被构建成胖 JAR（fat JAR），其中内置了所有的依赖，然后作为一个单独的 Java 进程存在。

 

Q：微服务业务层如何进行分层？业务系统如何定级，标准为什么？

一般微服务的分层需要根据公司的自身情况。

 

同一公司使用统一应用分层，以减少开发维护学习成本。应用分层看起来很简单，但每个程序员都有自己的一套方法，哪怕是初学者，所以想实施起来并非那么容易。

 

最早接触的分层架构应该是我们最熟悉的 MVC（Model-View-Controller）架构，其将应用分成了模型、视图和控制层，可以说引导了绝大多数开发者。而现在的应用（包括框架）中非常多架构设计都使用此模式。之后又演化出了 MVP（Model-View-Presenter）和 MVVM（Model-View-ViewModel）