1、摘要:

        2017年10月，我被任命为系统架构师参与了XXX 运营商AOP 系统架构升级项目，负责架构设计工作，该系统是运营商面向互联网销售产品的系统，自从年中上线流量包订购业务以来，系统订单量飞速上涨，月末订单量达 10 余万笔，客户希望通过营销活动进一步提升订单量，并承载更多业务，但我们评估当前架构无法支撑客户需求，因此提出本项目。
        本文以此项目为例，论述了微服务架构的在项目中的实际应用;首先我梳理了微服务架构的思想、优点和挑战因素，然后分析了本项目的系统现状、影响可靠性的风险点，再大致交代了解决可靠性问题的举措，然后重点论述了采用微服务架构如何达成架构升级目标;最后制定了本次架构升级的技术方案，评审并实施后，经过 1年多来的稳定运行，成功达成了设计目标，获得客户一致好评。

2、正文：

        微服务，是面向服务架构的一种，顾名思义，微服务架构下，服务的粒度很小，每个服务专注于一件事情，微服务架构提倡将系统拆分成一系列细粒度的服务，通过服务的编排组合实现业务需求，服务间通过轻量级通讯协议交互，从而支持微服务架构的系统达成松耦合、组件化、高扩展、高弹性、可修改行、可替代性俱佳的目标，最终提高系统的交付速度，提高交付质量。
微服务的好处很多，首先，它很适合成为新技术的试验场，每个服务都是独立的，可以根据服务自身需要采用合适的技术，如社交网络适合采用图数据库，而结构化数据适合采用关系数据库;其次，微服务系统对外提供了众多的服务，系统的可组合性好，业务变化时能轻易组合服务实现;再次，微服务的可替代性、弹性、可扩展性都很好，服务可以独立替换，每个服务可以内置自己的降级限流方案，也可以独立扩展性能，方便调整系统的整体处理能力。

        微服务虽说有很多好处，但也有很多挑战，首先，几乎所有业务需求都需要通过服务的编排组合实现，服务间的通讯开销可能影响性能，同时数据的一致性、可靠性等都可能受影响;其次，运维成本高，相对单体应用，微服务数量众多，每个微服务都需要独立部署，运维监控、运行成本高昂;再次，自动化部署的要求，服务间依赖关系的管理，服务依赖的测试都是挑战，需要妥善解决。

        微服务架构只是一种理念，具体的实现框架技术中，Springloud 无疑是最为成熟的，Spring 生态强大的集成能力体现无疑，微服务各方面的需求都有对应的组件能满足，如服务网关 Zuul、注册中心Eureka.容错降级 Hystrix、客户端负载均衡 Ribbon、配置中心 Springcloudconfig等，为微服务系统开发提供了全面的支持，除此之外，基于阿里巴巴开源的 Dubbo 服务治理框架也是一种选择，相对来说它没有那么全面的组件支持，但国内应用此框架较多，经历过互联网企业巨大流量的历练，框架成熟度较高。

         2017 年10 月，我被任命为系统架构师参与 XXX运营商AOP 系统的架构升级工作负责架构升级方案制定，组织架构升级工作实施，本次架构升级的目标是提高系统的性能扩展能力和可靠性，为互联网营销活动提供支撑。该系统是 XXX 运营商面向互联网销售产品的系统，目前承载了宽带业务订购、存费送费活动、流量包订购等业务，其中流量包订购业务占据总体业务量的绝大部分，月底订购高峰时日订单量超过10万笔，客户对系统现状较为满意，希望能通过系统进行互联网营销活动，如红包、满减、直降、抢购等大家都知道这些营销活动时用户请求将呈现指数级增长，我们评估目前的系统架构难以支撑此类需求。

        当前系统是基于轻量级J2EE 架构，大体上可分为两个子系统，订单处理子系统和接口子系统，因运营商的业务复杂、支撑系统众多，简单的流量包订购业务涉及多达 6 个系统提供的近 10 个接口，订单处理子系统的一部分工作就是调度后端系统接口完成业务需求;两个子系统通过 Dubbo 服务治理框架交互，订单处理子系统和接口子系统都是单体系统，分别部署了3 个和5个节点，数据库为 2台双机热备，前端接入采用一台 nginx反向代理。

        分析完系统现状后，我们分析了影响系统可靠性、扩展性的薄弱点:1、nginx 的单点失效风险;2数据库的性能瓶颈; 3、单体应用中的服务雪崩风险，服务间未做隔离，很容易一个服务的问题影响到整个系统;4、快速交付要求下的系统部署风险，客户要求支持每周进行营销活动，目前架构下单体应用没有时间经过充分测试。

        以上薄弱点中，nginx失效风险可以增加 nginx 节点，前置负载均衡器解决;数据库性能瓶颈可通过订单处理异步化部分解决(只能缓解，仍存在瓶颈);服务雪崩和快速交付风险，甚至数据库瓶颈，我们考虑可以通过微服务架构解决。

        微服务架构可以很完美的实现服务隔离，可以从物理上隔离服务占用的资源，配合降级机制可以较完美的解决服务雪崩风险;此外，配合良好的 DevOps 工具链，微服务系统可以单独发布影响到的服务，影响范围很容易控制，而营销活动时基本上都是独立开发一个或少数几个附加服务，对整体逻辑基本不影响，能很完美的达成快速交付目标，最后，进行促销活动的一般只有流量包等热点业务，微服务架构下我们可以将这些热点业务的订单数据库独立出来，甚至营销活动的服务独立数据库，然后通过 binglog 将订单数据同步到全订单库。

        确定好微服务架构思路后，我们评估了当前微服务架构实现方案，出于平滑过渡、保护原有投资、工期等因素，最后我们决定采用Dubbox方案实现，Dubbox 是当当网基于Dubbo2.5.3 继续开发的，增加了Restful、Kyro等协议支持，具体设计方案及迁移路线图如下:
1、Dubbo2.5.3迁移到 Dubbox2.8.4，经灰度环境全面测试正常后，迁移生产环境
2、构建容器环境:当前系统是运行在云平台上的，但云平台未提供容器服务，向运营商云平台申请资源，与云平台协商，提供预装了容器环境的虚拟机镜像，我们项目新申请的资源统一使用此镜像3、搭建 Jenkins 工具链，测试 DevOps 自动化部署、自动化构建流水线，培训运维、开发人员掌握Devops模式的开发部署流程，配合容器化环境实现性能高效扩展。
接口子系统拆分，在建立上述基础设施后，基本按每个接口一个服务方式拆分，同时每个服务内置4、超时处理和降级措施;因接口的逻辑相对简单，比较容易切分，考虑到处理性能且不直接对外，服务通过高效的 kyro 协议交互。
5、订单子系统拆分，订单处理逻辑较为复杂，因此只考虑把热点业务拆分，每个热点业务的订单处理独立服务，本期只有流量包业务;且独立数据库，订单处理异步化，收单先入库到 redis 中，同时记录文件日志以防万一时补偿;订单处理过程全部在通过 redis 进行，同时另开同步线程池将脏订单数据入库到订单库:处理完的订单及时从 redis 中清理，以降低 redis 持久化的开销;最后基于阿里巴巴 Canal 将订单表同步到总订单库中。

        按上述思路输出设计方案后，我们召集内外部专家、客户一起评审，大家基本认可此方案，补充部分细节后，经过近 2个月的实施，系统成功上线，上线 2 年来，系统运行稳定，扩展性、可修改性、灵活性、可靠性、交付速度都得到大幅提高，得到客户一致好评，团队也经此一役得到锻炼，此后的微服务系统实施更为得心应手。

        此项目的设计过程让我深深体会了架构师就是在各种方案间权衡这句话，要达到架构升级的目标不止这一种方案，不采用微服务，通过线程池隔离+异步处理+数据库集群也能基本解决问题，实施工期、实施风险也要小一些，但解决问题不够彻底，且难以达成客户提高交付速度的要求，但若工期、成本不允许的话也可能采用这种方案。通过此项目更能认识到架构师宽广的技术视野非常重要，要不断学习，跟进技术发展，以设计出更适合的架构，为各方创造最大价值。