论微服务架构
目录
摘要
该平台系统是一站式全网整合活动平台系统，帮助中小微企业智能发展，提供全方位的营销活动服务。
本论文结合作者的实践，讨论了微服务架构风格在2b2c混合的活动平台中的应用。首先概述了平台的管理与开发，并采用微服务架构设计，然后介绍了微服务架构的特点，最后结合活动平台描述了系统如何采用微服务架构风格，并说明了采用微服务架构后遇到的实际问题与解决方案。通过合理的架构设计，系统在次年5月顺利发布RC版本并持续迭代，基于微服务架构的基础不断补充新的活动微服务，得到用户的认可与好评，由于活动本身良好的传播性，累计C端用户两千多万。
正文
项目背景
移动互联网时代，用户对活动需求持续增长，但活动供需信息不对称，公司决定研发综合性活动平台（以下简称为：“平台”），为中小微企业提供活动组织发布服务，同时为用户提供更丰富的活动搜索服务。
项目概述
平台主要应用有：官网站点群、活动管理系统、运营管理系统、App、公众号、微信小程序。平台支持多种活动类型，比如报名、预约、投票、抽奖、小游戏类营销等活动。
平台围绕活动提供以下服务：纵向上为B端用户主办方提供活动发布与管理服务，同时为C端用户提供全端活动搜索服务；横向上为B端用户提供不同类型的活动服务，如报名、预约、营销活动等，同时为C端用户提供不同模板的活动呈现服务；最后运营提供运营管理中台服务，负责中台业务与数据管理配置，比如审核、统一配置、消息、客服、智能推荐、财务、日志分析、风控配置等。由于篇幅原因，不再细化功能介绍。
微服务及特点
传统单块架构在构建部署和扩展伸缩方面有很大的局限性，比如简单的三层单块架构，系统中的任何调整都需要重新构建和部署新版本，影响范围广。在扩展方面，只能是整个应用横向扩展，难以针对模块单独扩展，难以充分利用资源，存在碎片浪费。微服务架构轻松的解决了这些问题。微服务是基于SOA的升华，微服务架构强调一个重点：业务需要彻底的组件化和服务化。原有的单个业务系统要求拆分为多个可以独立开发、设计、运行的子应用，这些应用之间通过轻量级的服务通信来完成交互与集成。而微服务架构其实就是一个服务治理方案。
相比较于单块架构，微服务架构具有多个特点：
- 1、通过服务实现组件化。开发者不需要协调其他服务部署对本服务的影响。
- 2、按业务能力来划分服务和开发团队。开发者可以自由的选择开发技术，提供API服务。
- 3、去中心化。每个服务都有自己的数据库，也只能访问自己的数据库，通过微服务架构访问其他服务数据库业务数据。去中心化进一步降低系统的耦合性。
- 4、基础设施自动化；把系统拆分成多个应用服务，应用容器技术，通过自动化方式独立部署，每个服务互相不影响，通过轻量通信机制联系，经常基于HTTP资源API，实现集中化管理。
微服务架构应用
由于活动平台的公共模块及活动类型多且独立，都强调了单一业务独立，非常适合微服务架构的服务组件化、去中心化特点，除了公共应用如用户管理、运营管理、分享推广、订单支付等，我们还把每一种活动类型作为单独的应用服务，如报名活动、预约活动、抽奖、投票、邀请函、开奖等活动，甚至后续加入小游戏类活动，每一个活动功能开发成独立的微服务，在容器中独立运行。这些微服务可以使用不同的语言、开发模式、团队、存储技术实现，并通过自动化部署工具独立发布。
由于我们团队内已有成熟的Spring体系相关开发经验，所以我们也采用了Spring Cloud服务框架。
服务之间需要创建一种服务发现机制，服务启动时会将自身服务信息注册到注册中心，服务注册中心选择使用Eureka，其已经经过大规模生产验证，并支持跨数据中心，客户端还支持灵活软负载；
服务网关选择了Zuul，其支持灵活的动态过滤器；配置中心选用SpringCloud Config。
通信协议采用有丰富经验的REST风格，采用REST实现微服务之间的协作通信。一般同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。REST基于HTTP，更容易实现，更容易被接受，服务端实现技术也更灵活些，各个语言都能支持，同时能跨客户端，对客户端没有特殊的要求，只要封装了HTTP的SDK就能调用，所以相对来说可使用的应用服务更广一些。
在日志监控方面采用ElasticSearch+LogStash+Kibana。以上基本满足当前规模的服务治理。
服务容错采用快速失败、失效切换的策略，如果多次连续失败，服务检测后直接熔断，不再发起调用，可以避免一个服务有问题连锁拖垮其他依赖服务，最后导致雪崩。
遇到问题与解决方案
由于单个服务越来越多，需求的多样性与关联性，每个服务难免会有业务上往来，涉及到频繁的对外通信，当微服务一直增加后，复杂度也在递增，如何提供一个高效的集群通信机制成为我们面临的一个问题。这个会是我们后续努力去解决的一个问题。
服务的负载均衡评估目前还不够成熟，只能通过平台自身的不断试探试错，我们通过这两年的经验总结出了一些合理的调度策略，还在持续优化。
总结
项目经过内部多次版本迭代，最终在次年5月完成RC版本，并对外发布，经过2年多的发展，累计C端用户两千多万，得到用户和团队的认可。由于微服务架构的设计，我们都能快速的支持新的活动类型与模块，在短时间内赶上竞品，由于功能模块/活动服务的独立，我们可以快速精准的修改以满足用户需求，也能快速调整满足运营数据验证。虽然各方面实现到位，但在结构清晰功能分明的架构下，是牺牲了部分性能，所以我们也针对部分单独服务实现多层缓存，表现层缓存，应用层缓存，服务层缓存，数据层缓存；另外由于微服务架构在多层服务调用，在比如一些短时间高并发场景，比如大量僵尸用户刷票场景时，容易导致服务器连接超出，引起cpu上涨，高负载导致宕机，引入人机验证服务及队列服务，缓解服务器tcp连接请求，保证服务器可用性。
通过这个产品项目，我们实在的感受到软件系统架构设计的重要性，也感受到随着业务需求的增多和变化，给架构带来了各种各样的挑战，而通过合理的的软件架构，不但提高了开发维护效率、运营效率，降低成本，并提高了系统的可维护性、可扩展性、可复用性、可移植性，加速了团队成长及产品验证速度。
