转载

微服务化的道与术

微服务的目标是提高响应能力，降低复杂度，让一切去中心化是微服务的最高宗旨。
复制代码

背景

随着研发团队的项目工程的增加、代码量的膨胀、团队人员的增长，传统的单体架构的弊端越来越凸显，严重影响了业务的快速创新和敏捷交付。随行付在2015年底为了解决传统单体架构面临的挑战，先后经历了单体架构、系统模块拆分以及到现在的微服务化。

微服务架构并非银弹，它的实施过程中会面临很多的陷阱和挑战、几乎影响到整个软件开发的生命周期，稍有不慎，会导致整个微服务改造的效果大打折扣，甚至失败。

本公众号接下来的一段时间会协同随行付架构部、随行付技术委员会等技术团队，结合随行付的一些实际经验，论证微服务架构实施的道与术。

微服务原因

为什么要做微服务化？可以从以下三个方面看为什么搞微服务。

分而治之：减低复杂性
分而用之：提高可重用性
分而做之：提高开发效率

可以用变化的成本来衡量架构的好坏。而架构的目的是管理复杂性、易变性和不确定性，以确保系统在进化过程中，架构的变化不会对应用产生不必要的负面影响。保证业务和研发效率的敏捷、保证易变应用频繁响应市场需求而中台部分的影响尽可能的小。

10几年前，一提到架构，大多数人都会认为，架构=性能+高可用。随着现在的技术不断更新(Docker、人工智能、区块链等技术)、各类开源软件异军突起、DevOps理念深得人心、敏捷开发成为主流开发模式等等，性能和高可用已经不再是那么棘手的问题。应用如何可持续发展？产品如何能快速上线/快速迭代？可维护性、可扩展性、成本，开始慢慢成为很多架构师的关注点。而微服务架构的根本目的就是降低复杂性。

微服务前提

业务拆分

采纳微服务架构首当其冲的问题就是根本没有一个确定的、良好定义的算法可以完成服务的拆分工作。像软件开发本身，服务的拆分和定义更像是一门艺术。更糟糕的是，如果你对系统的服务拆分出现了偏差，你很有可能会构建出一个「分布式的单体应用」，一个包含了紧耦合服务的必须部署在一起的系统。这将会把单体架构和微服务架构两者的弊端集于一身。

自动测试

微服务一个明显的表象就是随着服务的增多，如果继续沿用传统的测试模式就会遇到瓶颈，为了保证高效的迭代，尽量做到测试自动化。通过自动化让测试也可以「一处编写，处处运行」、让回归测试日常化。

自动运维

当互联网发展到今天，业务要保持对市场变化的一个高效响应，自动化运维就是提升交付速度的一个重要环节。微服务拆分之后，每个服务都可以独立部署，不再是固定的时间段去升级，人肉运维已经成了阻碍进步的绊脚石了。

多维度监控

硬件环境、服务状态、系统健康度、服务调用情况、异常的实时告警以及生产事故的事先预警等等。监控在实施微服务过程中至关重要。

道篇

微服务架构原则

技术栈统一

一定要使用成熟技术，充分考虑新技术带来的性价比。所谓成熟不仅仅是指有良好的社区活跃度、稳定性、节约开发成本、提高开发效率。更多的是指在随行付的技术普适度，说白了就是有多少人会，出了问题有多少人能hold住。

数据最终一致性

权衡好哪些服务是最终一致、哪些必须是强一致。而强一致的保障机制是什么？框架层和应用层相互互补来共同保障数据一致性。

服务无状态

对于无状态服务，首先说一下什么是状态。如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个「状态」数据的服务被称为有状态服务，反之称为无状态服务。那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的「有状态数据服务」中。

场景说明：例如我们以前在本地内存中建立的数据缓存、Session缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。

无状态通信，我们推荐使用Restful通信风格，因为他有很多好处：