微服务+架构 = 敏捷

文章导读：
本文为金兰软件技术负责人大苹果（孙爱红）的文章。金兰软件是从事企业大数据研发的美资企业。我们一起看，有着多年企业大数据研发经验的老司机给我们说点啥。

 微服务+ 架构 = 敏捷
 

微服务架构简介

随着业务复杂性的增加、遗留代码及新增业务逻辑代码的不断添加，企业软件也逐渐庞大起来。几年、十几年的项目做下来，代码结构可能已经变得非常难以维护，系统组件之间的耦合性也不像当初设想的那么完美，而更多新的业务需求还在不断的加入进来，甚至新的独立系统也要不断的集成进来。软件研发和维护变得越来越像一个噩梦。

当新技术、新趋势不断涌现时，软件架构也在不断进化，以更好的解决研发和维护过程中出现的这些问题，让软件研发和维护更高效、错误率更低。上世纪80年代软件架构主要是运行在大型机上的事务系统，90年代之后，个人电脑带来了客户机服务器架构，

而进入2000年后，互联网的发展和数据的分布、同步则降低了基于事务的交易系统的核心地位。现如今，移动互联网、终端设备的多样化，则希望软件系统能够更好地适应用户的需求、随时随地的可访问。在这种情形下，更加灵活的微服务（Micro-service）架构出现了。

那么什么是微服务呢？实际上，微服务是可独立运行和部署的专注于更特定的、更集中的业务功能的服务组件。比如说多语言软件中，用于提供语言包功能的微服务、用于日志记录的微服务、用于用户权限认证的微服务等。

我们为什么需要微服务呢？微服务架构能解决我们当前遇到的什么问题？在传统的软件研发中，软件的功能都包含在同一个可执行的软件包中、或者类库、或者依赖于同一个数据库。然后编写完成的软件部署到一个CPU和内存足够大的服务器或者虚拟机上。

对于大多数一般的应用程序来说，这样做就已经足够了。但是，随着系统业务越来越复杂、系统越来越庞大，尤其是企业级应用，系统所需的资源越来越多，有限的CPU和内存会逐渐成为性能的瓶颈。在我做过的很多大型的企业系统中，几年、十几年不断的添加新功能、维护旧功能，系统的性能调优似乎成了后来的主要工作。不断的去优化复杂的数据库存储过程、不断的去重构复杂的程序代码，可是依然不太理想。

这个时候，我们开始想要把复杂的业务逻辑按照功能逐渐剥离出来，让它们有独立的可执行程序、独立的数据库、可以独立的编译打包部署，从而可以为这些独立的可执行程序分配程序运行所需的资源，相互不依赖，减少性能瓶颈。这些独立的微服务可以使用通用的协议，比如RESTful API来进行通信和交互。独立的微服务有很好的可扩展性，当某一个微服务有性能瓶颈时，只需要再多部署一些这样的服务，就能把性能压力分散开。所以，微服务是解决因资源限制而导致系统性能瓶颈的一个有效措施。

这种设计同时也遵循了软件设计上的关注点分离（Separation of Concerns，SOC）的原则。

而从大型软件的研发管理上来说，关注点更集中、可独立部署、执行的微服务，能让团队立即开始一个微服务的研发。从各个微服务起，逐个击破，让大型系统的成功研发、维护更可管理。尤其是在当下DevOps被广泛应用之时，更小单元的微服务能更容易地在DevOps平台上实现自动代码提交、编译、部署和测试。

另外，有了这些微服务组件，整个软件系统可以更容易的部署到云平台上。根据计算资源的需要，可以部署到一个或多个虚拟云平台上。也可以根据业务功能的需要，启动或关闭某一些微服务。所以，这种微服务的架构非常适应当前的云计算环境。

在这一篇文章中，我们简单介绍了微服务的背景知识、为什么需要使用微服务。

后面我会分三个部分给大家阐述。第二部分，将结合实际的案例，来说明微服务设计的原则、基于RESTful的微服务设计等。

在第三部分里，将结合Scrum敏捷模型、DevOps平台，介绍一下微服务是如何应用在这些场景。

作者：孙爱红 （金兰（大连）软件技术公司 技术负责人，21CTO社区CTO俱乐部会员）