微服务架构实践心得小结

                                        微服务架构实践心得小结

来源：彗星计划

简介

微服务架构

微服务架构则是由一组微服务组成的架构模式。每个微服务都是一个可独立部署的完整系统。一组微服务组成微服务层（注意这里的服务层不同于monolithic架构中的服务层，那个是单系统中的功能模块分层）。微服务层上面一般是应用层，应用层通过组合使用微服务层的各个微服务而向外提供接口（比如HTTP API接口）。各个微服务可以通过RPC接口供应用层调用，比如利用Thrift、Avro。

单体架构

单体架构指的是应用被以单一单元构建。比如豆果包含菜谱、用户、商家、商品、订单、支付等业务功能模块，从代码上可以简单理解是需要合在一起部署的。

重构背景

豆果美食最早上线于08年底，是一个只有PC端的个人网站，发展到现在豆果美食全屏覆盖（包括手机、PC、TV、厨房智能家居设备），APP截止目前总下载量超过1.3亿，注册用户超过3000万，日活180万+，UGC上传菜谱量 80万+，总作品量600万+。 业务从原来单一的上传分享菜谱，到现在的菜谱+社区+电商的三大产品线。

业务的快速发展，一直在不断的尝试新功能、找新的模式，技术团队根本一直都在不断的满足业务需求，增增减减，几年下来导致系统务必的庞大复杂。无论是开发、测试、维护还是运维都极度复杂，在弹性、扩展性、可维护性方面也困难重重，根本都不敢动。具体的面对的问题大致有： 1、团队分工协作难 人数多了，并不能实现效率的提升，大家还是纠缠在一个大项目中，并不能根据业务、产品线来做开发，导致产品需求部门对研发的开发效率有极大的抱怨。 2、被阉割了的扩展能力 单体架构下，整个系统作为一个强耦合的整体，无法根据业务功能伸缩，只能作为一个整体进行扩展。这造成资源浪费，同时无法针对不同业务模块的特性进行有针对性的伸缩，比如计算密集型服务、IO密集型服务。 3、阻碍技术更新换代 因为单体架构下，很难做一些新的尝试，牵一发而动全身，基本上几个月就基本全部搞熟了，接下来每天都是这些套路，需要做的更多是跟业务、产品扯皮，这个做不做。怎么做都已经被限定死的，对团队士气、学习积极性是一个打击，也削弱团队的吸引力。 4、业务监控难做 无论是业务的服务监控、还是业务指标监控，越加越臃肿，极大的影响干扰正常业务的运行和维护。

还有其他的诸如 服务等级、安全要求、监控需要针对不同维度不同的业务实现不同的功能要求，单体架构很难实现，迫使转向服务化，采用微服务的架构。

微服务架构设计模式

我们用的是最常用的一个模式，聚合式的微服务架构设计。如下图所示：

聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的Web页面，将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务，对 检索到的数据增加业务逻辑后进一步发布成一个新的微服务，这符合DRY原则。另外，每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务，那么它也 有自己的缓存和数据库。聚合器可以沿X轴和Z轴独立扩展。 我们将用户、菜谱、订单、商家、商品等都做成了一个个独立的微服务，对上层应用提供数据。

迁移到微服务架构的准备工作

这有一个前提就是一定要有人对原来的系统、业务非常熟悉，可以抽丝剥茧，先划分成若干模块，一块一块替换，这一步是能否实施成功的关键之一。刚好豆果从第一行代码就是我写的，不然以我们的经验，这里坑太多，会出现纯靠运气迁移，风险太大，大到迁移会被各种原因搁置，最后不了了之。 在划分完各模块，还需要做3个维度的准备：

1、工具化、自动化 在测试、部署方面一定要提前准备好自动化工具，不然一旦迁移到微服务架构下，团队成员需要管理大量独立的服务，其复杂度和测试难度是几何级增加，没有方便的工具，基本推进执行不了，阻力不是一般的大，整个转型过程会异常艰辛痛苦，感觉全部人都站到你对立面去啦。

2、新的架构设计原则 采用微服务架构，应用交付高度复杂化。架构设计原则需要从原来单体式架构下的关注功能、性能等维度向MVP（最小可用产品）、面向失败的设计（拥抱失败，而不是阻止失败）、宽进严出（对请求宽进严出，对外的响应要严格规范化）、宁花机器一分，不花人工一秒（自动与自助、复杂重复的事情交给平台工具去做，让程序员去做更有价值的事情）、一切皆资源等设计原则转变，形成架构渐进优化的设计风格。

3、团队变革

微服务架构本质上在强调松耦合的架构，在微服务架构迁移前最好重新分配一下团队，独立小组负责独立服务。 我们对团队成员的分工有了一个改变，专人专项，主要负责某个模块，在迁移开发的时候，也是由这人独立交付一个微服务，全程负责，从开发跟到测试到上线。这极大的提供团队成员的责任感，加速微服务的自治和交付能力。

微服务架构改造需要遵循的原则

基于业务进行拆分、采用自动化文化、去中心化、服务独立部署、服务完全自治、隔离失败、渐进式拆分、避免大规模改造原有代码等原则，这些原则相信关注微服务架构的已经相对清楚。结合我们具体的实践，分享一下我们的经验：

1、先分离数据库、后分离服务 数据模型能否彻底分开，决定了微服务的边界功能是否彻底划清。这个一定要把核心的做彻底，不然来回返工会是迁移完以后会频繁出现的状态，极大的伤害积极性。针对数据库强烈建议一个微服务对应一个库；

2、替换代替打补丁

很多系统因为历史遗留原因没法修改，或者改不动，直接搁置旧系统，所有新的功能单独拎出来做微服务，老的就不管了。这种情况一般来说都不是特别重要的系统，会被逐渐替代、清除掉；

3、建立统一的日志规范

规范整个系统而非微服务的日志体系，采用标准的日志格式非常便于后续的日志聚合检索，便于整体的视角分析、监控、查看系统。我们采用 logstash+ElasticSearch+kibana 实现了服务的类即时监控。

微服务架构改造平滑迁移

迁移过程是最心惊胆战的时刻，但是前面的准备做好了，其实也还好。另外结合我们的迁移的经验，我总结了2点：

1、工具很重要，没有自动化的测试、部署工具，以及配套的日志分析监控系统，迁移工作无从论起；

2、小步快跑，不重要的模块做试点，等工具以及这些操作熟悉了，就可以迁移重点模块；

下图是我们迁移后的架构图

小结

微服务架构的优缺点都一样明显， 优点： 1、明确的模块边界：微服务强化了模块化结构，这对于大型系统来说尤为重要。 2、独立部署：简单的服务很容易部署，由于是自治的，因此当某个模块本身出现问题时一般不会导致系统崩溃。 3、技术多样性：借助于微服务，你可以混合使用多种语言、开发框架和数据存储技术。 缺点： 分布式带来的开发、维护、以及保持强一致性的难度大大提高，对于团队的能力要求较高；

所以微服务并不适用于初创团队项目或者中小项目，另外我们实施完微服务架构后，确实对于团队组织结构的扁平化以及每个人的责任心有一个很大的变化。

参考资料

1、http://www.infoq.com/cn/news/2015/06/DOA-Microservice 

2、http://martinfowler.com/articles/microservices.html

版权申明：内容来源网络，版权归原创者所有。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表示歉意。谢谢。

-END-