微服务架构凭借其高便捷性、可拓展性等优势受到了广泛关注，然而很多团队在如何选择微服务架构上经常会遇到困惑。
在近日举办的个推TechDay系列线上技术沙龙上，个推高级平台架构师悟空、高级基础架构研发工程师阿飞以“微服务架构实践”为主题，深入浅出地讲解了微服务架构的特性、选择以及实践等要点，分享了自己在深耕微服务领域多年的实战经验。
以下是微服务专场的精华内容摘录
（文章结尾附视频链接&讲师分享PDF下载）
《微服务漫谈》
本文主要从四个方面介绍微服务：
微服务简介
微服务的优缺点
微服务的配套设施
微服务的选择
01
微服务简介
2014年，Martin flowler和他的同事对微服务的基本概念做了精确描述，其核心点为：
1. 它是一套小的服务；
2. 独立部署，运行在自己的进程里；
3. 每个服务为独立的业务开发；
4. 分布式的管理（去中心化）。
微服务与单体的区别在于，单体是在一个服务进程里运行所有的业务逻辑，开发的时候已经做了功能模块的划分；而微服务，是把每个功能模块拆分之后再进行独立部署。微服务架构紧密围绕业务领域，形成高度内聚的自治性，可根据需要独立扩容相关服务，且职责单一。
▲ 单体架构（左）和微服务架构（右）对比
02
微服务的优缺点（对比单体架构）
单体架构又称为“洋葱架构”，其主要优点为：结构简单，容易理解；对开发人员要求相对低；部署简单方便；运行高效。
单体架构存在的缺点也很明显，例如隔离性差，易耦合；难以扩展，易达极限，不能针对某些高频接口进行扩展部署，增加了测试成本；稳定性保障难，一出问题，整体服务瘫痪等。
综上，单体架构适用于中小型应用开发。
▲ 单体架构
微服务架构强调 “微”，它能快速创建，也能快速销毁；能够相互组合，也能快速拆散。微服务的目的是有效地拆分应用，实现敏捷开发和部署。其主要优点为：降低了复杂度；代码容易理解，开发效率提高；隔离型好，易扩展；微服务之间相互独立，一个出现问题，不会影响全局服务；单个服务方便交付等。
但也存在一些缺点：微服务对团队的技术要求更高；分布式管理和通信成本高；数据一致性及性能复杂度高，整个链路变长后，任何一个环节出现瓶颈，会导致整个接口性能下降，升级兼容性也相对比较复杂。
▲ 微服务架构
03
微服务的配套设施
微服务的配套设施主要为服务发现、负载均衡、服务网关、分布式配置、服务熔断和APM服务监控，这里主要讲述CI/CD、DevOps和容器化。
CI/CD：缺乏持续集成和持续交付流程会使团队无法拥有支持微服务开发和交付所必需的敏捷性。简单地说，服务拆分了后，有很多的服务要去并行开发、测试，这时如果没有自动化的过程，仅靠手工来做，工作效率非常低，此时就需要CI/CD的支撑。
▲ CI/CD进程
DevOps：字面意思是由开发来运维，体现了敏捷开发的概念。
容器化：容器化是将微服务进程和应用程序隔离到更小的实例里，提升了资源利用率。容器化和微服务两者之间是相互结合的，容器化为微服务有效地达成了轻量和高效的目的。
04
微服务的选择
关于如何选择微服务，主要考虑三点：
第一是业务复杂度，简单的业务建议采用单体架构，如果考虑到后期业务发展会比较快，可以考虑微服务架构；
第二是团队规模，微服务本身的管理成本非常高，适合有一定规模的团队；
第三是技术积累，在没有完善的技术积累下，仓促地使用微服务，生产效率的曲线下降得可能比单体更严重，因此刚开始需要有个专门的人或团队提供基础设施的保障。
▲ 单体与微服务架构的生产效率曲线图
对于微服务架构的最佳实践，我们总结如下：
1.数据独立，不耦合。微服务的数据应该尽量独立，如果把后端存储全部存储在一个数据库中，仅仅把前端的业务逻辑拆分到不同的服务进程中，这种不拆分存储的微服务是“伪”服务。
2.业务允许的情况下尽量不用分布式事务。因为分布式事务的效率较低，也相对难以实施，能够在业务层面解决的问题，尽量不要用去技术去解决。
3.缓存和异步化。缓存中需要考虑到缓存穿透和雪崩等问题。异步化分为业务和技术层面，业务层面需要考虑是否可以尽可能地快速响应结束，不让用户等待，技术层面我们可以采用一些异步非阻塞的技术，例如协程、消息队列等。
4.考虑故障恢复＞避免故障发生。
5.建议统一开发语言。
总的来说，微服务不是银弹，不能解决所有的问题，它是应对大型复杂应用系统时，通过服务拆分的方法，达到高效敏捷的实施目的。在微服务的思维上，技术本身不是太大的问题，意识比工具更重要。
《个推微服务网关架构实践》
在微服务架构的基础上，我们进一步讲解个推在微服务网关架构的实践，主要从微服务网关的作用、设计要素、技术选型、具体实现这几个方面进行。
01
微服务网关的作用
微服务网关是微服务架构中的一个关键组件，它的作用主要体现在以下几个方面：
1. 提供统一的服务入口，所有访问后台服务的流量都要经过微服务网关，由微服务网关统一路由。
2. 对所有的访问进行身份认证、权限管理、流量控制等管理功能，减少重复建设。
3. 对流量进行集中式管控，如链路追踪、流量监控，便于运维、问题排查。
02
微服务网关的设计要素
1. 高可用：要选用成熟和经过验证的技术，支持分布式扩展，避免单点故障；
2. 高性能：不能有性能问题，不应该成为整个系统的瓶颈，流量要实现负载均衡；
3. 安全：要实现对流量的身份认证和鉴权，能够对请求进行安全过滤，支持限流限次；
4. 动态路由：作为微服务的统一入口，能够对流量进行动态路由；
5. 流量的集中式管控：支持链路追踪、日志记录、流量监控；
6. 功能便于扩展：能够方便进行功能扩展。
03
微服务网关的实现
如上图所示，Openresty对请求分为四个大的阶段：
1.Initialization Phase
2.Rewrite/Access Phase
3.Content Phase
4.Log Phase
在Initialization阶段一般会初始化网关实例，对请求的处理主要发生在后面三大阶段的六个子阶段：
set_by_lua*
rewrite_by_lua*
access_by_lua*
header_filter_by_lua*
body_filter_by_lua*
log_by_lua*
具体的设计参考了Kong和Orange的设计，通过插件的机制来实现，这样可以方便扩展网关的功能，并且可以根据流量特征选择不同的插件组合，同时每个插件可以单独进行开发，互不影响。
在具体实现中，我们以产品为维度，限定插件的组合和作用顺序，每个产品的流量请求只能按固定的顺序由固定插件组合处理，如下图所示，我们会通过如下配置来指定product1和product2使用的插件和顺序：
product1={'rewrite_uri','dyups','auth'},
product2={'rewrite_uri','dyups_svc','zipkin'}
每个插件通过配置设定自己起作用的子阶段，如上图rewrite_uri插件，作用是重写请求的URI，配置了作用的子阶段为set_by_lua*和rewrite_by_lua*，同时负责实现每个阶段的具体处理逻辑。
每个插件各自实现自己的过滤规则和过滤逻辑，如rewrite_uri插件配置了一条如下的规则：
pattern=[^/api/demo/(\w+)/(\w+)\?(.*)$],
tmpl='/demo/$1/$2?$3'
表明能够匹配到pattern中的正则表达式的请求，都会被该插件处理，处理后URI会根据tmpl中的模版被rewrite成/demo/$1/$2?$3的形式。
这样一次请求到达网关后，我们首先可以通过其从属的产品选择对应的插件组合，再根据各个插件的过滤规则筛选匹配到的插件，最后按配置的插件顺序依次对请求进行处理。
这样的设计保证了不同的产品可以使用不同的插件组合，方便了网关功能的扩展，同时保留了插件实现的灵活性，每个插件可以自定义适合自己的过滤规则。
以上主要介绍了个推微服务网关的架构设计和具体实现，总结如下：
1. 微服务网关对于微服务有重要作用，是微服务的统一入口；
2. 在做微服务网关设计前，我们根据自身具体的业务场景确认了微服务网关的设计的要素和功能需求；
3. 具体技术选型参考较为成熟的开源解决方案Kong和Orange，并结合了自身实际情况；
4. 为了保证网关的灵活性和扩展性，架构采用了插件机制，并且给了各个插件自定义过滤规则的自由。
PDF获取方式
关注【个推技术学院】微信公众号
（微信号：getuitech）
回复关键词“微服务”
即可领取微服务专场完整版讲师分享PDF！
【微服务专场】已圆满结束
错过的小伙伴可以通过下方链接观看回顾视频：
https://live.vhall.com/room/watch/504315119