微服务架构模式（microservice architect pattern）是近两年在软件架构模式领域里出现的一个新名词。虽然其诞生的时间不长，但其在各种演讲、文章、书籍上所出现的频率已经让很多人意识到它对软件领域所带来的影响。
那到底什么是微服务，当我们谈论微服务时，它代表着一种什么样的含义？微服务适合应用在什么场景下，以及它有什么样的优缺点？微服务和soa到底有没有区别？微服务的核心功能点有哪些？ 微服务如何治理？本文依次为你揭开面纱 ！
单体架构
在讲微服务之前，让我们先回顾一下传统的三层应用架构的发展历程并认识一下什么是单体架构应用，因为微服务就是在单体架构之后衍生出来的。
常见三层架构模型
在软件架构模式的领域，随着面向对象分析、面向对象设计、面向对象原则、设计模式、企业架构模式等理念以及方法论的不断发展，从为用户提供功能、以及有效组织软件结构的角度考虑，web 应用中不同职责的部分逐渐被定义在了不同的层次，每一层负责的部分更趋向于具体化，细致化，于是软件的三层架构逐渐出现了。三层架构通常包括表示层、业务逻辑层以及数据访问层。
单体三层架构模式如下：
.
表示层部分通常指当用户使用应用程序时，看见的、听见的、输入的或者交互的部分。譬如，有可能是信息的显示，音乐的的播放或者可以输入的文本框，单选按钮以及可点击的按钮等。通过这些元素，用户同软件进行交互并获取期望的价值。
业务逻辑层
业务逻辑部分是根据用户输入的信息，进行逻辑计算或者业务处理的部分。业务逻辑层则主要聚焦应用程序对业务问题的逻辑处理，以及业务流程的操作，它是大部分软件系统区别与其他系统的核心。譬如，当用户点击一个按钮后，它可能会触发业务逻辑部分的代码进行运算，生成用户期望的结果。
数据访问层
在用户同应用程序交互的过程中，会产生数据。这类数据需要通过某种机制被有效的保存，并在将来能够被重复使用，或者提供给其他系统。这种机制或者方法就是数据访问层最关注的部分。也就是说，它关注的是应用程序是如何有效的将数据存储到数据库、文件系统或者其他存储介质中。有一点要注意的是，它关心的是对原始数据的操作（数据库或者文本文件等存放数据的形式），而非原始数据的存储介质本身。
这也就是我们常见的mvc模型，m--model，对应数据访问层，v--view，对应表示层，c---control，对应业务逻辑层。
单体架构【单块架构】
虽然软件的三层架构帮助我们将应用在逻辑上分成了三层，但它并不是物理上的分层。这也就意味着，即便我们将应用架构分成了所谓的三层，经过开发团队对不同层的代码实现，经历过编译（如果非静态语言，可以跳过编译阶段）、打包、部署后，不考虑负载均衡以及水平扩展的情况，最终还是运行在同一个机器的同一个进程中。对于这种功能集中、代码和数据中心化、一个发布包、部署后运行在同一进程的应用程序，我们通常称之为单体架构应用。
单体架构的优势
易于开发
对单体架构的应用程序而言，开发方式相对较简单。首先从概念上，现有的大部分工具、应用服务器、框架都是这类单体架构应用程序，容易理解而且为人所熟知。如果从实践角度出发，现有的集成开发工具比较适合单块架构的应用程序。
易于测试
单块架构应用程序也非常容易被测试，因为所有的功能都运行在一个进程中，启动集成开发环境或者将发布包部署到某一环境，一旦启动该进程，就可以立即开始系统测试或者功能测试。
易于部署
对单块架构的应用程序而言，部署也比较容易。实际上，由于所有的功能最终都会打成一个包，因此只需复制该软件包到服务器相应的位置即可。
易于水平伸缩
对单块架构的应用程序而言，水平伸缩也比较容易。实际上，由于所有的功能最终都会打成一个包，且只能运行在一个进程中，因此单块架构的水平伸缩，更确切的理解其实是克隆，即新建一个服务器节点，配置好该节点的运行环境，复制软件包到相应的位置，运行改应用程序。当然，必须要确保负载均衡器能采取某种分发策略，有效的将请求分发到新创建的节点。
单体架构的劣势 & 面临的挑战
随着最近几年互联网行业的迅猛发展，随着公司或者组织业务的不断扩张，需求不断的增加以及用户量的不断增加，单体架构的优势已逐渐无法适应互联网时代的快速变化，面临着越来越多的挑战。譬如说，一方面，随着业务的扩大，如何为用户提供可靠的服务，如何有效处理用户增多后导致并发请求数增多，导致的响应慢的问题，以及如何有效解决用户增多后带来的大数据量的问题等。另外一方面，随着公司或者组织业务的不断扩张，需求不断的增加，越来越多的人加入开发团队，代码库也在急剧膨胀。在这种情况下，单体架构的可维护性、灵活性在降低，而测试成本、构建成本以及维护成本却在显著增加。
研发成本高：代码重复率高，需求变更困难，无法满足新业务快速上线和敏捷交付
代码维护成本高：本地代码在不断的迭代和变更，最后形成了一个个垂直的功能孤岛，只有原来的开发者才理解接口调用关系和功能需求，新加入人员或者团队其它人员很难理解和维护这些代码。
测试、部署成本高：业务运行在一个进程中，因此系统中任何程序的改变，都需要对整个系统重新测试并部署。
新人培养周期长，要熟悉所有庞大的代码
技术选型成本高：不利于调整其中某个功能的框架
可伸缩性差：水平扩展只能基于整个系统进行扩展，无法针对某一个功能模块按需扩展。
可靠性差：某个应用bug，例如死循环、oom等，会导致整个进程宕机，影响其它合适的应用
依赖关系无法有效管理：服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。
持续交付周期长 & 构建全功能团队难
以上问题的应对策略，那就是微服务化，微服务化之前，首先要先对原有单体架构进行拆分。
微服务出现的意义所在
如果以上问题得以认可，那么我们再回过来考虑一下，微服务出现的意义在哪里呢？它的优势有哪些呢？如何保障义务演进但是系统架构还是依然往好的方向发展呢 ？
随着公司产品线的不断扩大，业务系统越来越多，功能逻辑也越来越复杂,而之前发all-in-on的架构部署形态,也慢慢的不适应于当前的现状。随着工程产品如美拍、电商、闪聊、以及云服务的发展,服务会倾向于服务化的部署方式,从而来解耦服务之间的依赖,利于多团队的协作,同时也利于业务系统的优化和管理,同时也利于后续的服务调度和资源的精细化管理。
对美图公司而言，目前公司各部门的服务调用方式:
网络平台和架构平台的服务之间的调用,是以http的方式,基于nginx简单的负载均衡策略,节点的上下线基于nginx的节点探测的方式
网络平台内部之间的调用,除了http外,还在一小部分服务使用yar的方式进行调用,基于lvs做负载均衡
电商平台,目前会以doubbo来搭建整套架构,而与外部的服务的调用方式,初期会以http的方式,进行互操作
大数据部门和其他部门,是以http的方式进行调用
目前公司各部门的开发语言:
架构平台:golang、java、c/c++、lua
网络平台:php、lua 大数据平台:java
广告平台:java
电商平台:java
随着业务的发展,各部门之间的技术体系,会越走越远,从而会给美图的服务端系统的稳定性和可运维性带来很大的挑战,所以目前需要有一个统一的微服务架构的实践,来统一解决当前的架构问题,防止架构腐化,提升系统的稳定性。这是美图公司微服务化的意义，相信也是其他公司所面临的问题和意义所在。
如何拆分
既然我们已经认可要将单体架构所面临的问题进行解决就必须要服务进行拆分，那么我们需要考虑的还有如何拆分？先拆分哪些服务？如何推进？ 等等
首先，需要对业务进行拆分。当业务量大了以后，特别是当不同的功能耦合在一起的时候，任何一个地方的改动都是非常困难的，必须对业务进行拆分，拆分的策略有两种：
横向拆分。按照不同的业务域进行拆分，例如订单、商品、库存、号卡资源等。形成独立的业务领域微服务集群。
纵向拆分。把一个业务功能里的不同模块或者组件进行拆分。例如把公共组件【如redis、memcache、mysql、elasticserach、kafka】拆分成独立的原子服务，下沉到底层，形成相对独立的原子服务层。这样一纵一横，就可以实现业务的服务化拆分。
其次，要做好微服务的分层：梳理和抽取核心应用、公共应用，作为独立的服务下沉到核心和公共能力层，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
微服务复杂性的处理方式
如何保证微服务化后面临的其他问题？
服务的分拆肯定会让结构更加复杂，但微服务在理念描述上已经意识到，从服务架构着眼，设计上考虑了部署的问题，运营在架构中的优先级也是排在第一位的，而以往在设计模式、软件架构基本不会考虑到部署、运营的问题。所以，如果要支持微服务架构，必须有一套行之有效的运营、部署的工具和方式，这也是容器相关技术和容器云现在备受关注的一个原因。
对于依赖的问题，包括一部分的复杂性问题，取决于拆分时候边界和接口的定义、数据联通的方式，设计得是不是足够合理，服务提供者是不是清楚需求的方式，服务调用者是不是理解接口的意图，也就是说团队针对每个服务的沟通，对事情的定位，对接口的抽象，是不是有一个同样的认知水平，达成一个共识。只要保证接口稳定、合理，实现不管怎么变化，对整合架构就不会有负面影响。服务的局部修改反而可以更快速，因为不会涉及一个大系统的调整。
所以说，不能为了拆分而拆分，拆分的意图要准确描述问题的解决。在一个系统里面，定义接口比怎么实现更重要，不要设计不好理解、不合理的接口。
微服务架构概览
看到这里，相信我们已经有了一个基本理念就是我们传统的mvc软件架构模型，传统的all-in-on部署形态已经无法满足互联网时代了，微服务是必选项了。那么接下来，我们来好好聊一聊微服务是个啥？ 服务化架构怎么设计？
服务化架构的演进历史
在实施微服务架构之前，我们一起回顾下服务化架构的演进历史。
.
mvc
mvc架构大部分人都用过，它主要用来解决前后端、界面、控制逻辑和业务逻辑分层问题。比较流行的技术堆栈就是spring + struts + ibatis（hibernate）+ tomcat（jboss）---- 这个我不熟悉。
rpc
随着业务特别是互联网的发展，业务规模的扩大，模块化逐步成为一种趋势，此时解决模块之间远程调用的rpc框架应运而生。rpc需要解决模块之间跨进程通信的问题，不同的团队开发不同的模块，通过一个rpc框架实现远程调用，rpc框架帮业务把通信细节给屏蔽掉，但是rpc框架也有自身的缺点。
rpc本身不负责服务化，例如：服务的自动发现不管、服务的应用和发布不管、服务的运维和治理也不管。没有透明化、服务化的能力，对整个应用层的侵入还是比较深的。
soa
soa服务化架构，企业级资产重用和异构系统间的集成对接，soa架构的现状：在传统企业it领域，主要是解决异构系统之间的互通和粗粒度的标准化（webservice）。互联网领域，提供一套高效支撑应用快速开发迭代的服务化架构。例如各个互联网公司自研或者开源的分布式服务框架。
微服务定义
很难对微服务下一个准确的定义。就像nosql，我们谈论了好几年的nosql，知道nosql代表着什么样的含义，也可以根据不同的应用场景选择不同的nosql数据库，但是我们还是很难对它下一个准确的定义。实际上，从业界的讨论来看,微服务本身并没有一个严格的定义。不过，thoughtworks的首席科学家，马丁-福勒先生对微服务的这段描述，似乎更加具体、贴切，通俗易懂：
微服务架构（microservice architect）是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于http协议的restful api）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
总结下来，微服务的特点应该是满足如下：
彼此独立：既然是一个独立的服务，那必然是一个完整的自治系统，不依赖外部的东西就能够提供服务。有自己一整套的完整的运行机制，有和外部通讯的标准化接口。
原子化：作为一个微服务，一定是一个原子...