工欲善其事，必先利其器。前面我们介绍了微服务架构的一些组件和为什么要选择SpringCloud Alibaba作为微服务架构的实现。这篇文章我们一起来看看，到底什么是微服务？它又能解决哪些问题？它的特点又是什么呢？
1、什么是微服务架构？
首先，到底什么是微服务架构呢？微服务这个词出现的年代其实并不久远，在2011年的一场架构师研讨会上，微服务的概念第一次被人提及，但当时并未给出微服务的明确定义。后来随着技术的不断发展，在2014年3月份，有一篇博客发表的关于微服务特点的文章，对微服务的概念做了明确的定义。
所谓微服务架构风格是一种将单机应用程序开发为一组小型服务的方法，每个小服务运行在自己的进程中，并以轻量级的机制来进行通信。这些服务围绕着业务能力所建立，并且由完全自动化的部署机构独立部署，这些服务的集中管理只有最低限度，可以用不同的编程语言编写并使用不同的数据库存储技术。
以上就是关于微服务最初时的定义。概念可能过于模糊，我们通过一个架构演化的例子来大致描述一下微服务架构。
2、分布式应用有哪些问题？
要搞清楚微服务架构，首先我们需要看一下分布式架构到底有哪些问题。
在早期构建的分布式应用时，多应用系统间协作其实是件比较困难的事情。比如如下应用系统：
比如入上的金融企业的贷款服务。按照贷款的业务职能，将平台分解为4个部分，分别是产品超市（门户网站）、风控系统、贷后系统和催收系统。
业务流程是：
- 用户在产品超市挑选自己需要的贷款产品。
- 系统将用户个人的基本信息和贷款产品传入风控系统进行资格审查和风险评估。
- 如果用户满足产品的贷款要求，则将信息发送给贷后系统执行后续的放款流程。
- 完成贷款后，通过催收系统通知贷款人定期还款。
这个业务流程我们可以看出，是将一个完整的业务流程拆解了4个子系统。每个子系统都有单独的团队进行维护，因为没有统一的标准，便容易出现以下一些问题：
（1）通信困难
假如风控系统需要向贷后系统发送一个调用请求，通过webservice来实现，在webservice跨进程调用时，需要双方持有相同传输对象才可以完成数据交互。但如果服务提供者将服务升级后，客户端没有及时通知时，则会因为对象状态不一致而导致数据交互失败。要知道在开发领域，接口升级及拓展是常有的事儿，如果这类问题一再出现，必然会影响系统的稳定性和团队之间的协作。这是第一个问题。
（2）内部的系统复杂度对外暴露
假如贷后系统为了高可用，提供了IP为01、02两个节点，风控系统客户端持有这两个静态IP地址。但随着业务的发展，贷后系统的负载越来越大，贷后系统集群加了03和04两个节点，如何通知风控系统拓展这两个节点呢？因为在原始并没有设计这样的动态扩展机制，导致风控系统必须手动配置这两个节点，并重启应用才可以。这就导致两个子系统出现了非常强的耦合，并且风控系统必须了解贷后系统的每台服务器的运行情况，提高了项目的维护难度。
（3）调用复杂
四个子系统在业务流转中，需要不断地进行相互调用和交互。业务简单还好，如果业务更复杂，工程师想梳理各子系统间的调用时机和交互方式，就会非常困难。这里也就需要一种中间件帮我们梳理清楚系统间的调用关系。
（4）重复建设
因为四个系统是各个团队独立维护，但又需要一些基础的模块。比如：鉴权、黑名单白名单、流量控制、异常处理及参数配置等。当没有统一的服务时，就需要各个团队自行研发使用。不同的团队又有不同的实现思路和业务设置，导致基础模块重复建设，也不利于数据的集中管理。
（5）统一的架构设计
在上述的四个子系统中，即使是各个团队分别负责，但都隶属于同一家单位，那么就导致各团队需使用公司统一的技术体系进行实现。比如，公司统一要求数据存储在Oracle数据库集群中，但产品超市系统实际业务中需要大量的全文检索服务。全文检索并不是Oracle这种关系型数据库擅长的，实际应该交给Elasticsearch全文搜索引擎来处理。
对于产品超市子系统的这个需求，需要额外引入Elasticsearch集群。因为这是产品超市子系统独有需求，所以理应由产品超市子系统的团队来独立管理与维护。但由于统一架构的要求，其他子系统也必须要支持Elasticsearch，这显然是不合理的。
以上几个弊端，只是传统分布式架构中的一部分问题，其他的问题就不一一列举了。
3、微服务又如何解决这些问题呢？
微服务的特点有三个：
- 基于业务、可重用、职责明确的构建小型服务。
- 统一通信标准，轻量级的通信协议。这里指restful。
- 可独立运行，独立存储，由独立团队进行维护。
那么当使用微服务对上述子系统进行改造后，架构会变成什么样子呢？
将原有的各个子系统中的核心服务进行抽象，形成服务层，在服务层又可以按照是否与业务相关来分为业务服务层和基础服务层。
其中业务服务层是从各子系统中抽取出来可以被重用的服务模块，并有着独立的数据库进行存储，由独立的业务团队维护。
基础服务层则是抽象出与业务无关的底层基础设施，例如数据同步、配置中心等服务，它是面向所有服务对外暴露的。
以上就是改造后的微服务架。那么，分布式系统传统的问题如何通过微服务架构解决的，我们来分别看一下。
第一，微服务架构提供了统一的进程间通信标准，以上述风控与贷后系统通信为例。之前采用webservice要求客户端与服务端必须持有相同的通信对象。在改为restful通信后，restful是基于http协议的轻量级通信方式，它并不强制要求客户端持有通信对象，可以使用httpclient或者okhttp组件，发起标准的http请求就可以通信。返回的数据也是标准的json结构，这样一来，服务端即使进行了响应数据拓展，在后续的通信时也不会强制要求客户端进行升级适配，服务端与客户端是彼此兼容的。
第二，屏蔽了分布式应用的复杂度，假设风控服务增加了两个节点，对于微服务架构来说，它有个关键组件-注册中心，所有服务的IP地址以及节点状态都是由它来维护的，调用方是不需要了解风控服务有具体的几个节点的。这就有效降低了应用之间的耦合，提高了程序间的可维护性。
第三，内建链路跟踪体系，在分布式应用中，要梳理服务间的调用关系，实际上是一件很繁琐的事情。但在微服务架构体系下，这个问题就很好解决。因为微服务标准中提供了链路跟踪的技术实现。比如有A、B、C三个服务，ABC三个服务间的调用顺序和调用时长一目了然。通过可视化实现，就可以很直观的了解到各服务间的通信过程及通信状态：
第四，减少重复建设，基础数据管理更加集中。在微服务体系中，有一个认证中心的服务，其本意是在前端应用发起实际请求前，对用户的身份和权限进行校验，不同系统的认证过程都是类似的，把它抽象出来做一个通用的认证中心，不仅可以减少每个子系统的重复建设，还可以将用户信息进行集中统一存储，为后续的数据分析做铺垫。
第五，架构设计更弹性。比如上述需求，产品超市需要提供全文检索服务，那么就可以专门为产品超市服务增加Elasticsearch服务进行支持，并不会影响其他服务的运行。那么后续如果其他服务也需要全文检索功能，那么对应的自行接入全文检索服务即可。
可以看到，引入微服务后因为有了统一的分布式应用标准，以往分布式系统中遇到的各种问题都可以得到比较合理的解决。
但，微服务并不是万能的，任何架构都有自己缺点，大家可以提讨论一下：在改造成微服务后，会产生哪些新问题呢？
欢迎关注公众号：服务端技术精选，留言讨论。