随着中国特色互联网企业的快速崛起，微服务架构已经成为最近热炒的名词。在长沙，也相继有包括微医、校管家等先进互联网企业逐渐开始应用微服务架构构建企业技术栈核心，并为公司的飞速发展从技术上扫清了障碍。然而，必须深刻的认识的一点是，在互联网时代的星城长沙，固然有包括海商、芒果TV等企业在内的多家企业，但是与国内互联网行业发展水平相比差距甚远，已经逐渐成为互联网技术发展的荒漠。原因有多种多样，但是技术人才缺失也已经成为关键的一环，尤其是DotNET开发领域，了解AOP\IOC\DI\微服务等技术的人实际上已经非常少了。本系列也是溪源第一次以公开笔名的方式发布技术文章，并希望通过此系列文章的发出，为长沙微服务发展提供一丝微薄的助力。我相信，每一个人多做一点点，全行业都会进步一大步。溪源也是一位传统领域开发者，对微服务架构的认识也仅仅停留在理论层面，如有不足之处，还望大家批评指正。

        按道理，第一个议题，首先应该谈一谈与微服务相关的关键词，但是由于篇幅关系，为了更好的阐述这块内容，本人在《初识微服务 二》中单独进行了说明，包括领域驱动模型（DDD)、DevOps、Docker、Consul、k8s、rancher、Zookeeper等。应该说涉及的理论概念非常多，已经不是三言两语可以说明白的，包括溪源的理解也不一定正确，只希望通过我的解释，能够让一些人听懂，就心有安慰了。在本系列中，本人以一个理想化的仓储管理系统的实现过程作为实例进行应用，本人的理解均来源于互联网及《微服务设计原理与架构》一书，期待引起各位专家的拍砖。

究竟什么叫做微服务？

        按照长沙IT圈技术大佬财哥的说法，应该分成广义和狭义之分。

        广义应该是指传统服务架构下，对服务的足够细分，例如，在在一个理想化传统仓储系统中，将库存设计成仓储信息表、仓储出入账两个表，可以将仓储信息维护（CRUD)、出库、入库分成3个单一的服务，并使用IIS进行部署，即可成为一种微服务。

        而狭义，则应该参见百度百科的解释：“微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。”，参考《原理》一书中的说法一些具有足够小的粒度、能够相互写作，且自治的服务体系。两种说法，虽然看上去有一点点区别，但是都有一个共同点：1、粒度足够小、2、能够自治。因此，从概念是来看，广义的微服务，仅仅只能称为一种足够小的业务服务，而不能称为真正的微服务。

什么叫做微服务架构？

        微服务架构首先表现为一种分布式系统（Distributed System)，而分布式系统实际上是对传统单体应用程序的一种演进。

       单体系统

        在上述理想化的仓储系统中，通俗而已，会采用类似于mssqlserver的形式构建一个数据库、并使用asp.net mvc构建一个网站，并使用iis进行发布，用户可通过网络访问该系统，实现对仓储行为的操作。大概表现为下图：

                                                                        （图1）

        在ASP.NET程序员眼里，一眼可以看出，这是一个传统的MVC开发模式的网站，同时他也是目前长沙市场上最为普遍的一类系统架构，即为单体系统，简单来说就是一个系统中，所有设计的组件都打包为一体化结构并部署和运行。除此之外，大家所应用的包括WebAPI在内的各类SOA服务架构，事实上也属于单体系统（别跟我说webapi按业务拆分成几万个网站在独立分发，我无言以对）。在这种单体系统中，所有组件都作为一个整体进行统一的开发、部署和维护。显然，图1所示系统有广泛的应用优势，在企业规模较小、团队较小时，一个单体应用可以由小团队进行独立维护，同时，如果要进行功能上进行CRUD操作，同样也非常简单，只需在控制器上新增功能即可、如果遇到问题，大不了采用aspectCore或者autofac等架构进行解耦合即可，遇到性能瓶颈，也可以用负载均衡策略（nginx）并运行单块系统的多个实例即可达到系统伸缩性的要求。但是这是长久之际么，如果系统规模逐渐扩大，例如怎么维护？这成为了一个问题。当然，在传统企业开发者眼里，规模扩大是一个软件横向扩展的问题，可以通过更加完善的产品化、模块化等方式实现，但是在互联网开发者眼中，则有不同的想法。

        互联网人怎么想？

        在互联网领域，系统的复杂度并非单单体现在业务的扩大上，例如从原本的一个表，扩充成十个表、一百个表？这并非互联网领域首先要考虑的问题。互联网技术人首先考虑的是，从十个人，扩展到一万个人，十万个人、一亿用户怎么办？业务复杂度的提升、代码腐化、团队问题、伸缩性问题都是需要考虑的问题。因此，这种基于传统的单体应用的横向扩展，已经不在适应互联网快速发展的需要，迫切需要一种新的技术来解决上述问题。因此分布式系统就是在这个背景下产生。

                                            图2，单体应用升级之分布式纵向拆分示意图

                                                                图3，分布式横向拆分示意图    

    当然，分布式系统经历了很多个阶段，也不在赘述。总之，当分布式系统逐渐抽象化到一个层次后，专家们发现，基于领域驱动设计，对系统进行纵向扩展、或横向扩展，实际上是可以将服务拆分成很多个工作单元，从而最终形成了微服务架构。

     实质上，微服务架构依旧是一种SOA架构，不过新增了许多新的理念，这些新的理念包括以下方面：

    基本特性：

    1、微服务的大小（粒度）

    通常喜欢用软件包的大小或软件的行数来横向软件的大小、或者用费用和开发周期来进行区分，但是这不是一个科学的衡量指标。按照前文说的粒度只是一个方面，实际上应该小到专注与某一个具体业务功能，也就是说首先应该保证每一个微服务都具备业务独立性的工作单元，应该根据业务便捷来确定服务的便捷，这样可以将与业务有关的内容都集中在微服务内部，从而实现了服务的高内举行。服务的大小也与团队的规模和工作方式有较大关系，如果一个系统规模达到无法通过独立团队进行开发和维护，那么按照职能进行拆分实际上的普遍的选择，这也是微服务的一种实践方式。

    当然，随着服务的逐渐细分，其业务独立性和内举行固然会带来优势，但是同样也导致服务数量过多，管理成本必然也连带增加。

    2、微服务的交互

        微服务代表的一种具体的业务功能、具有高度的内聚性，并运行与独立的进程中。因此，微服务之间的交互实际上是网络环境下分布式的交互模式，通常，微服务之间通常使用RPC或消息传递的形式进行交互，能够提供松耦合的架构体系，每个微服务都可以在不影响其他微服务的前提下进行独立的修改、发布和部署。对于微服务而言，我们应该明确其对业务的抽象成都以及对外暴露这种抽象程度的方式。应该为每个服务定义访问入口，并确保接口本身与实现的技术无关性。

        在技术实现上，应该采用一种轻量级的通信方式进行交互，为了提高访问性能，通常会使用长连接的形式，但是这种模式会使得通信过程耦合性提高，一旦出现问题，会导致问题如同涟漪般在整个分布式系统中扩散，导致服务不可用。如果使用HTTP协议，应该让服务之间的通信变得标准化和无状态化。

        微服务的大小和交互方式构成了微服务基本的体系结构，分别代表了微服务高内聚、低耦合的基本特性。这样是软件开发者追求的终极目标。