基于微服务架构，改造企业核心系统之实践

1. 背景与挑战

随着公司国际化战略的推行以及本土业务的高速发展，后台支撑系统已经不堪重负。在吞吐量、稳定性以及可扩展性上都无法满足日益增长的业务需求。对于每10万元额度的合同，从销售团队准备材料、与客户签单、递交给合同部门，再到合同生效大概需要3.5人天。随着业务量的快速增长，签订合同的成本急剧增加。

合同管理系统是后台支撑系统中重要的一部分。当前的合同系统是5年前使用.NET基于SAGE CRM二次开发的产品。 一方面，系统架构过于陈旧，性能、可靠性无法满足现有的需求。另一方面，功能繁杂，结构混乱，定制的代码与SAGE
CRM系统耦合度极高。由于是遗留系统，熟悉该代码的人早已离职多时，新团队对其望而却步，只能做些周边的修补工作。同时，还要承担着边补测试，边整理逻辑的工作。



相关厂商内容

发现日志对于安全的价值，以及如何使用
AWS CloudTrail满足合规性要求。

如何通过使用
AWS对IT资源实现高级别管控，并大规模实现更高级别的安全性？

Windows Azure从开发到部署的自动化进程

微软Windows Azure开启机器学习之旅

基于开源软件的Azure平台大规模系统构建

相关赞助商




Windows Azure专区上线，全面了解云服务精彩呈现！

在无法中断业务处理的情况下，为了解决当前面临的问题，团队制定了如下的策略：

1). 在现有合同管理系统的外围，构建功能服务接口，将系统核心的功能分离出来。

2). 利用这些功能服务接口作为代理，解耦原合同系统与其调用者之间的依赖；

3). 通过不断构建功能服务接口，逐渐将原有系统分解成多个独立的服务。

4). 摒弃原有的合同管理系统，使用全新构建的(微)服务接口替代。

2. 什么是微服务

多年来，我们一直在技术的浪潮中不断乘风破浪，扬帆奋进，寻找更好的方式构建IT系统。微服务架构(Micro Service Architect)是近一段时间在软件体系架构领域里出现的一个新名词。它通过将功能分解到多个独立的服务，以实现对解决方案或者复杂系统的解耦。

微服务的诞生并非偶然: 领域驱动设计指导我们如何分析并模型化复杂的业务；敏捷方法论帮助我们消除浪费，快速反馈；持续交付促使我们构建更快、更可靠、更频繁的软件部署和交付能力；虚拟化和基础设施自动化(
Infrastructure As Code)则帮助我们简化环境的创建、安装；DevOps文化的流行以及特性团队的出现，使得小团队更加全功能化。这些都是推动微服务诞生的重要因素。

实际上，微服务本身并没有一个严格的定义。不过从业界的讨论来看，微服务通常有如下几个特征:

小，且专注于做一件事情

每个服务都是很小的应用，至于有多小，是一个非常有趣的话题。有人喜欢100行以内，有人赞成1000行以内。数字并不是最重要的。仁者见仁，智者见智，只要团队觉得合适就好。只关注一个业务功能，这一点和我们平常谈论的面向对象原则中的”单一职责原则”类似，每个服务只做一件事情，并且把它做好。

运行在独立的进程中

每个服务都运行在一个独立的操作系统进程中，这意味着不同的服务能被部署到不同的主机上。

轻量级的通信机制

服务和服务之间通过轻量级的机制实现彼此间的通信。所谓轻量级通信机制，通常指基于语言无关、平台无关的这类协议，例如XML、JSON，而不是传统我们熟知的Java RMI或者.Net Remoting等。

松耦合

不需要改变依赖，只更改当前服务本身，就可以独立部署。这意味着该服务和其他服务之间在部署和运行上呈现相互独立的状态。

综上所述，微服务架构采用多个服务间互相协作的方式构建传统应用。每个服务独立运行在不同的进程中，服务与服务之间通过轻量的通讯机制交互，并且每个服务可以通过自动化部署方式独立部署。

3.微服务的优势

相比传统的单块架构系统(monolithic)，微服务在如下诸多方面有着显著的优势：

异构性

问题有其具体性，解决方案也应有其针对性。用最适合的技术方案去解决具体的问题，往往会事半功倍。传统的单块架构系统倾向采用统一的技术平台或方案来解决所有问题。而微服务的异构性，可以针对不同的业务特征选择不同的技术方案，有针对性的解决具体的业务问题。

对于单块架构的系统，初始的技术选型严重限制将来采用不同语言或框架的能力。如果想尝试新的编程语言或者框架，没有完备的功能测试集，很难平滑的完成替换，而且系统规模越大，风险越高。基于微服务架构，使我们更容易在遗留系统上尝试新的技术或解决方案。譬如说，可以先挑选风险最小的服务作为尝试，快速得到反馈后再决定是否试用于其他服务。这也意味着，即便对一项新技术的尝试失败，也可以抛弃这个方案，并不会对整个产品带来风险。



该图引用自Martin Fowler的Microservices一文

独立测试与部署

单块架构系统运行在一个进程中，因此系统中任何程序的改变，都需要对整个系统重新测试并部署。 而对于微服务架构而言，不同服务之间的打包、测试或者部署等，与其它服务都是完全独立的。对某个服务所做的改动，只需要关注该服务本身。从这个角度来说，使用微服务后，代码修改、测试、打包以及部署的成本和风险都比单块架构系统降低很多。

按需伸缩

单块架构系统由于单进程的局限性，水平扩展时只能基于整个系统进行扩展，无法针对某一个功能模块按需扩展。 而服务架构则可以完美地解决伸缩性的扩展问题。系统可以根据需要，实施细粒度的自由扩展。

错误隔离性

微服务架构同时也能提升故障的隔离性。例如，如果某个服务的内存泄露，只会影响自己，其他服务能够继续正常地工作。与之形成对比的是，单块架构中如果有一个不合格的组件发生异常，有可能会拖垮整个系统。

团队全功能化

康威定律（Conway’s law）指出：一个组织的设计成果，其结构往往对应于这个组织中的沟通结构（organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations）。传统的开发模式在分工时往往以技术为单位，比如UI团队、服务端团队和数据库团队，这样的分工可能会导致任何功能上的改变都需要跨团队沟通和协调。而微服务则倡导围绕服务来分工，团队需要具备服务设计、开发、测试到部署所需的所有技能。

4. 微服务快速开发实践

随着团队对业务的理解加深和对微服务实践的尝试，数个微服务程序已经成功构建出来。不过，问题同时也出现了：对于这些不同的微服务程序而言，虽然具体实现的代码细节不同，但其结构、开发方式、持续集成环境、测试策略、部署机制以及监控和告警等，都有着类似的实现方式。那么如何满足DRY原则并消除浪费呢？带着这个问题，经过团队的努力，Stencil诞生了。
Stencil是一个帮助快速构建Ruby微服务应用的开发框架，主要包括四部分：Stencil模板、代码生成工具，持续集成模板以及一键部署工具。

Stencil模板

Stencil模板是一个独立的Ruby代码工程库，主要包括代码模板以及一组配置文件模板。

代码模板使用Webmachine作为Web框架，RESTful和JSON构建服务之间的通信方式，RSpec作为测试框架。同时，代码模板还定义了一组Rake任务，譬如运行测试，查看测试报告，将当前的微服务生成RPM包，使用Koji给RPM包打标签等。

除此之外，该模板也提供了一组通用的URL，帮助使用者查看微服务的当前版本、配置信息以及检测该微服务程序是否健康运行等。

[
{
rel: "index",
path: "/diagnostic/"
},
{
rel: "version",
path: "/diagnostic/version"
},
{
rel: "config",
path: "/diagnostic/config"
},
{
rel: "hostname",
path: "/diagnostic/hostname"
},
{
rel: "heartbeat",
path: "/diagnostic/status/heartbeat"
},
{
rel: "nagios",
path: "/diagnostic/status/nagios"
}
]

配置文件模板主要包括NewRelic配置，Passenger配置、Nagios配置、Apache配置以及Splunk配置。通过定义这些配置文件模板，当把新的微服务程序部署到验收环境或者产品环境时，我们立刻就可以使用Nagios、NewRelic以及Splunk等第三方服务提供的功能，帮助我们有效的监控微服务，并在超过初始阈值时获得告警。

代码生成工具

借助Stencil代码生成工具，我们能在很短时间内就构建出一个可以立即运行的微服务应用程序。随着系统越来越复杂，微服务程序的不断增多，Stencil模板和代码生成工具帮助我们大大简化了创建微服务的流程，让开发人员更关注如何实现业务逻辑并快速验证。

Create a project from the stencil template (version 0.1.27)
--name, -n <s>:   New project name. eg. things-and-stuff
--git-owner, -g <s>:   Git owner (default: which team or owner)
--database, -d:   Include database connection code
--triggered-task, -t:   Include triggered task code
--provider, -p:   Is it a service provider? (other services use this service)
--consumer, -c:   Is it a service consumer? (it uses other services)
--branch, -b <s>:   Specify a particular branch of Stencil
--face-palm, -f:   Overide name validation
--help, -h:   Show this message

如上代码所示，通过指定不同参数，我们能创建具有数据库访问能力的微服务程序，或者是包含异步队列处理的微服务程序。同时，我们也可以标记该服务是数据消费者还是数据生产者，能帮助我们理解多个微服务之间的联系。

持续集成模板

基于持续集成服务器Bamboo，团队创建了针对Stencil的持续集成模板工程，并定义了三个主要阶段：

打包：运行单元测试，集成测试，等待测试通过后生成RPM包。

发布：将RPM包发布到Koji服务器上，并打上相应的Tag。然后使用Packer在亚马逊
AWS云环境中创建AMI，建好的AMI上已经安装了当前微服务程序的最新RPM包。

部署：基于指定版本的AMI，将应用快速部署到验收环境或者产品环境上。

利用持续集成模板工程，团队仅需花费很少的时间，就可以针对新建的微应用程序，在Bamboo上快速定义其对应的持续集成环境。

一键部署工具

所有的微服务程序都部署并运行在亚马逊AWS云环境上。同时，我们使用Asgard对AWS云环境中的资源进行创建、部署和管理。 Asgard是一套功能强大的基于Web的AWS云部署和管理工具，由Netflix采用Groovy
on Grails开发，其主要优点有：

基于B/S的AWS部署及管理工具，使用户能通过浏览器直接访问AWS云资源，无需设置Secret Key和Access Key；

定义了`Application`以及`Cluster`等逻辑概念，更清晰、有效地描述了应用程序在AWS云环境中对应的部署拓扑结构。

在对应用的部署操作中，集成了AWS Elastic Load Balancer、AWS EC2以及AWS Autoscaling Group，并将这些资源自动关联起来。

提供RESTful接口，能够方便地与其他系统集成。

简洁易用的用户接口，提供可视化的方式完成一键部署以及流量切换。

由于Asgard对RESTful的良好支持，团队实现了一套基于Asgard的命令行部署工具，只需如下一条命令，提供应用程序的名称以及版本号，就可自动完成资源的创建、部署、流量切换、删除旧的应用等操作。

asgard-deploy [AppName] [AppVersion]

同时，基于命令行的部署工具，也可以很容易的将自动化部署集成到Bamboo持续集成环境。

通过使用微服务框架Stencil，大大缩短了团队开发微服务的周期。同时，基于Stencil，我们定义了一套团队内部的开发流程，帮助团队的每一位成员理解并快速构建微服务。

微服务架构下的新系统

经过5个月的努力，我们重新构建了合同管理系统，将之前的产品、价格、销售人员、合同签署、合同审查以及PDF生成都定义成了独立的服务接口。相比之前大而全、难以维护的合同管理系统而言，新的系统由不同功能的微服务组成，每个微服务程序只关注单一的功能。每个微服务应用都有相关的负责人，通过使用Page
Duty建立消息通知机制。每当有监控出现告警的时候，责任人能立即收到消息并快速做出响应。



由于微服务具有高内聚，低耦合的特点，每个应用都是一个独立的个体。当出现问题时，很容易定位问题并解决问题，大大缩短了修复缺陷的周期。另外，通过使用不同功能的微服务接口提供数据，用户接口(UI)部分变成了一个非常简洁、轻量级的应用，更关注如何渲染页面以及表单提交等交互功能。

总结

通过使用微服务架构，在不影响现有业务运转的情况下，我们有效的将遗留的大系统逐渐分解成不同功能的微服务接口。同时，通过Stencil微服务开发框架，我们能够快速地构建不同功能的微服务接口，并能方便地将其部署到验收环境或者产品环境。最后，得益于微服务架构的灵活性以及扩展性，使得我们能够快速构建低耦合、易扩展、易伸缩性的应用系统。

参考文献

http://martinfowler.com/articles/microservices.html
http://jaxenter.com/cracking-microservices-practices-50692.html http://microservices.io/patterns/microservices.html

作者简介

王磊，ThoughtWorks公司的程序员，咨询师。开源软件的爱好者和贡献者，社区活动的参与者，Practical RubyGems的译者。于2012年加入ThoughtWorks,为国内外诸多客户提供项目交付和咨询服务；在加入ThoughtWorks之前，曾就职过多家知名外企，具有丰富的敏捷项目实战经验。目前致力于微服务架构、高可用性的Web应用以及Devops的研究与实践。

感谢张逸对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。

【QCon北京2015大会】把握趋势，邀请国内外顶级专家，设计涵盖大数据、云计算、移动开发、技术创业、前端和敏捷等热点领域的18个专题，IT领域的技术盛宴。了解详情。

领域

架构
& 设计

语言
& 开发

专栏

敏捷技术

最佳实践

持续集成

构建系统

敏捷

架构

微服务

相关内容

微服务学习资料汇总

CocoaPods达到每月一百万次下载量

基于Hadoop生态技术构建阿里搜索离线系统

Google发布针对构建错误的研究洞见

王海亚：淘宝交易系统演进之路

告诉我们您的想法

社区评论Watch
Thread

micro
services是思想不是技术 by l nj Posted 2014年10月27日 11:30

Re:
micro services是思想不是技术 by Zhefu Zhou Posted 2014年12月1日 06:22

micro
services是思想不是技术 by l nj Posted 2014年10月27日 11:30

和传统架构有什么好比的 by
sun shumin Posted 2014年10月27日 11:46

思想更重要 by
huang xiaodong Posted 2014年10月28日 12:49

Re:
思想更重要 by dandan wl Posted 2014年10月28日 01:19

Re:
思想更重要 by dandan wl Posted 2014年10月28日 01:19

思想重要，但实践更重要 by
dandan wl Posted 2014年10月28日 01:23

感觉像轻量级的SOA by
hedgehog yucca Posted 2014年10月29日 11:29

管理会不会是很麻烦的事情呢 by
黄 国华 Posted 2014年10月30日 03:45

Re:
管理会不会是很麻烦的事情呢 by dandan wl Posted 2014年11月3日 12:43

Re:
管理会不会是很麻烦的事情呢 by Zhefu Zhou Posted 2014年12月1日 06:18

micro services是思想不是技术2014年10月27日
11:30 by l nj
这种架构的好处都大家说烂了：解耦、分布式、可伸缩、异构、轻量级……在我看来，这些buzzy words都不是micro services独创的，话句话说，不是micro services的价值，那么为什么大家都在谈论和使用它？这篇文章有段话我特别认同：

“微服务的诞生并非偶然: 领域驱动设计指导我们如何分析并模型化复杂的业务；敏捷方法论帮助我们消除浪费，快速反馈；持续交付促使我们构建更快、更可靠、更频繁的软件部署和交付能力；虚拟化和基础设施自动化( Infrastructure As Code)则帮助我们简化环境的创建、安装；DevOps文化的流行以及特性团队的出现，使得小团队更加全功能化。这些都是推动微服务诞生的重要因素。”

也就是说micro services并不是什么技术创新，而是开发过程发展到一个阶段对技术架构的要求：这个要求就是快速和业务对齐（align business），它包括快速理解业务（DDD）、快速开发（Lean、Agile、VM）、快速反馈（CI）、快速交付（CD、DevOps）。

所以我认为micro services并不是技术，而是化整为零（或称分治）思想换了一种说法，无论是把一个大型系统分割成多个小而自治的系统，还是把一个大型团队分成多个team，或是把一个复杂的项目分成多个交付阶段都是这种思想的运用。至于其技术层面的价值，远没有其思想的价值大。

有些软件开发人员认为micro services是一种新技术，应该学习它使用了哪些框架，这就是舍本逐末了。

回复

回到顶部

micro services是思想不是技术2014年10月27日
11:30 by l nj
这种架构的好处都大家说烂了：解耦、分布式、可伸缩、异构、轻量级……在我看来，这些buzzy words都不是micro services独创的，话句话说，不是micro services的价值，那么为什么大家都在谈论和使用它？这篇文章有段话我特别认同：

“微服务的诞生并非偶然: 领域驱动设计指导我们如何分析并模型化复杂的业务；敏捷方法论帮助我们消除浪费，快速反馈；持续交付促使我们构建更快、更可靠、更频繁的软件部署和交付能力；虚拟化和基础设施自动化( Infrastructure As Code)则帮助我们简化环境的创建、安装；DevOps文化的流行以及特性团队的出现，使得小团队更加全功能化。这些都是推动微服务诞生的重要因素。”

也就是说micro services并不是什么技术创新，而是开发过程发展到一个阶段对技术架构的要求：这个要求就是快速和业务对齐（align business），它包括快速理解业务（DDD）、快速开发（Lean、Agile、VM）、快速反馈（CI）、快速交付（CD、DevOps）。

所以我认为micro services并不是技术，而是化整为零（或称分治）思想换了一种说法，无论是把一个大型系统分割成多个小而自治的系统，还是把一个大型团队分成多个team，或是把一个复杂的项目分成多个交付阶段都是这种思想的运用。至于其技术层面的价值，远没有其思想的价值大。

有些软件开发人员认为micro services是一种新技术，应该学习它使用了哪些框架，这就是舍本逐末了。

回复

回到顶部

和传统架构有什么好比的2014年10月27日
11:46 by sun shumin
要比就和SOA中的服务比一比，

我眼中的微服务和SOA中的服务无差别，只是粒度粗细而矣

回复

回到顶部

思想更重要2014年10月28日
12:49 by huang xiaodong
更多的是一种思想吧！就跟SOA一样。

回复

回到顶部

Re: 思想更重要2014年10月28日
01:19 by dandan wl
软件领域的思想确实非常重要，多少年来都毋庸置疑。实践者更是只有先充分理解理论，才能更好指导实践。

但话说回来，SOA提出了这么多年，更多人依然认为WS*即等同于SOA。

微服务也是一种架构思想，并不是什么技术创新，它最终也是围绕着业务，帮助企业解决业务问题的。

所以理解微服务架构没什么难的，更关键的是如何构建使用微服务的实践：

不管什么架构，能满足业务需求，能快速验证业务在市场的有效性，能快速将业务价值最大化，就是好架构，所以还是回到几个根本问题：

如何使业务想法快速上线？

如何降低运营成本？

如何快速定位并修复缺陷？

如何快速技术演进？

回复

回到顶部

Re: 思想更重要2014年10月28日
01:19 by dandan wl
软件领域的思想确实非常重要，多少年来都毋庸置疑。实践者更是只有先充分理解理论，才能更好指导实践。

但话说回来，SOA提出了这么多年，更多人依然认为WS*即等同于SOA。

微服务也是一种架构思想，并不是什么技术创新，它最终也是围绕着业务，帮助企业解决业务问题的。

所以理解微服务架构没什么难的，更关键的是如何构建使用微服务的实践：

不管什么架构，能满足业务需求，能快速验证业务在市场的有效性，能快速将业务价值最大化，就是好架构，所以还是回到几个根本问题：

如何使业务想法快速上线？

如何降低运营成本？

如何快速定位并修复缺陷？

如何快速技术演进？

回复

回到顶部

思想重要，但实践更重要2014年10月28日
01:23 by dandan wl
软件领域的思想确实非常重要，多少年来都毋庸置疑。实践者更是只有先充分理解理论，才能更好指导实践。

但话说回来，SOA提出了这么多年，更多人依然认为WS*即等同于SOA。

微服务也是一种架构思想，并不是什么技术创新，它最终也是围绕着业务，帮助企业解决业务问题的。

所以理解微服务架构没什么难的，更关键的是如何构建使用微服务的实践：

不管什么架构，能满足业务需求，能快速验证业务在市场的有效性，能快速将业务价值最大化，就是好架构，管它是SOA还是MS，所以归根基地，还是回到几个问题：

如何使业务想法快速上线？真的已经够快了吗？

如何降低运营成本？

如何快速定位问题并修复缺陷？

如何快速技术演进？

回复

回到顶部

感觉像轻量级的SOA2014年10月29日
11:29 by hedgehog yucca
和Soa的思想类似，个人觉得更像Soa的轻量级架构

回复

回到顶部

管理会不会是很麻烦的事情呢2014年10月30日
03:45 by 黄 国华
spring boot就是微服务的一个框架，但是其官方却一直强调的是提供开发的销量，有点特意逃避的嫌疑。我有个问题：如果我拥有众多的服务，成千上百的服务，每个都拆开的话，如何方便地去管理这么的微服务呢？或许不用每个服务都单独部署？那如何划分呢？

回复

回到顶部

Re: 管理会不会是很麻烦的事情呢2014年11月3日
12:43 by dandan wl
绝对会，微服务的应用带来的直接变化就是：

1. 开发变得更简单，快捷了。以前开发人员耗费时间来搭建环境、熟悉代码结构，在微服务的世界里会简单许多。

2. 但是测试，部署，运维和如何管理这么多服务之间的依赖，却带来了新的问题。

所以，对于微服务而言，更考验的是企业围绕业务，基于微服务的实践，如果构建更高效、更流畅、更低投入高产出比的实践。如果只谈“微服务就是SOA的轻量级，微服务的概念早就诞生了”这些理论，那就体现不了其真正的价值了。因为它并不是全新的技术和概念。

回复

回到顶部

Re: 管理会不会是很麻烦的事情呢2014年12月1日
06:18 by Zhefu Zhou
如何划分，要看领域模型的需求。说白了，能不能分解微服务，要不要做微服务，不是由技术人员的喜好决定的。我们的最终的目标就是要实现领域模型的要求，任何脱离这个核心思想所提出来的解决方案都不靠谱。

回复

回到顶部

Re: micro services是思想不是技术2014年12月1日
06:22 by Zhefu Zhou
某种程度上，你也可以说它代表了一族的技术。虽然说滇马可以爬山，川马也可以跑长途，但终究不能完全发挥它们各自的长处。要很好滴实现微服务架构，适当的新技术的采用有时候也是不可避免的。