实施微服务架构的五大原则.docx

实施微服务架构的五大原则“ 微服务化架构并非银弹，它的实施本身就会面临很多陷阱和挑战。本文从微服务的生命周期全过程，阐述微服务架构的改造如何实施，以及如何避开各种陷阱，提升实施效率。“前言随着业务的发展，代码量的膨胀和团队成员的增加，传统单体式架构的弊端越来越凸显，严重制约了业务的快速创新和敏捷交付。为了解决传统单体架构面临的挑战，先后演进出了SOA服务化架构、RPC框架、分布式服务框架，最后就是当今非常流行的微服务架构。微服务化架构并非银弹，它的实施本身就会面临很多陷阱和挑战，涉及到设计、开发、测试、部署、运行和运维等各个方面，一旦使用不当，则会导致整个微服务架构改造的效果大打折扣，甚至失败。本文从微服务的生命周期全过程，阐述微服务架构的改造如何实施，以及如何避开各种陷阱，提升实施效率。在实施微服务架构改造之前，我们的产品线遇到一个很大挑战，就是需求的交付周期越来越短，采用的传统MVC单体架构越来越难满足特性快速交付和上线的需求。传统的电信项目，团队规模往往都非常大，甚至会跨地域。跨团队、跨地域的分布式协同开发，代码的重用和共享是个难题。例如我们的支付功能需要新增一个限额保护， 短短十几行代码的一个小需求，评估之后竟然需要9个星期才能上线。原因就是限额保护功能需要同时在9个不同的功能模块中修改， 新增900多个测试用例用来做全量的回归测试，示例如下：通过对已有的MVC单体架构进行分析，我们发现主要存在如下几个问题：研发成本高：代码重复率高，需求变更困难，无法满足新业务快速上线和敏捷交付。测试、部署成本高：业务运行在一个进程中，因此系统中任何程序的改变，都需要对整个系统重新测试并部署。可伸缩性差：水平扩展只能基于整个系统进行扩展，无法针对某一个功能模块按需扩展。可靠性差：某个应用BUG，例如死循环、OOM等，会导致整个进程宕机，影响其它合设的应用。代码维护成本高：本地代码在不断的迭代和变更，最后形成了一个个垂直的功能孤岛，只有原来的开发者才理解接口调用关系和功能需求，新加入人员或者团队其它人员很难理解和维护这些代码。依赖关系无法有效管理：服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。以上问题的应对策略，就是服务化。首先，需要对业务进行拆分。当业务量大了以后，特别是当不同的功能耦合在一起的时候，任何一个地方的改动都是非常困难的，必须对业务进行拆分，拆分的策略有两种：横向拆分。按照不同的业务域进行拆分，例如订单、商品、库存、号卡资源等。形成独立的业务领域微服务集群。纵向拆分。把一个业务功能里的不同模块或者组件进行拆分。例如把公共组件拆分成独立的原子服务，下沉到底层，形成相对独立的原子服务层。这样一纵一横，就可以实现业务的服务化拆分。其次，要做好微服务的分层：梳理和抽取核心应用、公共应用，作为独立的服务下沉到核心和公共能力层，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。完成服务的拆分和分层工作之后，就会涉及到分布式的部署和调用。如何透明化、高效的发现服务，需要一个服务注册中心，通过服务化和订阅、发布机制对应用调用关系解耦，支持服务的自动注册和发现。服务化架构的演进历史在实施微服务架构之前，我们一起回顾下服务化架构的演进历史。MVCMVC架构大部分人都用过，它主要用来解决前后端、界面、控制逻辑和业务逻辑分层问题。比较流行的技术堆栈就是Spring + Struts + iBatis（Hibernate）+ Tomcat（JBoss）。RPC随着业务特别是互联网的发展，业务规模的扩大，模块化逐步成为一种趋势，此时解决模块之间远程调用的RPC框架应运而生。RPC需要解决模块之间跨进程通信的问题，不同的团队开发不同的模块，通过一个RPC框架实现远程调用，RPC框架帮业务把通信细节给屏蔽掉，但是RPC框架也有自身的缺点。RPC本身不负责服务化，例如：服务的自动发现不管、服务的应用和发布不管、服务的运维和治理也不管。没有透明化、服务化的能力，对整个应用层的侵入还是比较深的。SOASOA服务化架构，企业级资产重用和异构系统间的集成对接，SOA架构的现状：在传统企业IT领域，主要是解决异构系统之间的互通和粗粒度的标准化（WebService）。互联网领域，提供一套高效支撑应用快速开发迭代的服务化架构。例如各个互联网公司自研或者开源的分布式服务框架。微服务架构首先看一下微服务架构的定义：微服务（MSA）是一种架构风格，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。它有如下几个特征：小，且只干一件事情。独立部署和生命周期管理。异构性轻量级通信，RPC或者Restful。1.微服务架构的拆分原则微服务架构的实施过程中，首先遇到的最大的难题，就是它的拆分原则。微服