论微服务架构的应用
随着科技的进步以直播卖货为代表的新的销售渠道也深入人心，新的销售渠道也日新月异，在这样的背景下本人所在的手机制造公司于2019年2月决定开发一套新的电商系统，该系统除了自营电商外还需要全面打通与各直播卖货平台、第三方电商平台、小程序等平台的数据流转，及协调后方相关部门进行高效的动作。本人以平台部门的核心成员加入其中担任系统架构师职务。本文以此项目为例，论述了微服务架构在项目的实际应用，本文先讨论了项目的背景以及传统单体应用的问题以及缺陷；然后接着讨论微服务的思想、优点和挑战，论述了微服务架构框架的选择；最后述了微服务架构系统具体提高系统可靠性所使用的举措。系统经过半年多的研发系统顺利上线并接受了检验。
本人所在的公司为南方某手机制造企业，这几年随着国家经济的发展以及科技的进步，移动互联网得到了长足的快速发展，以抖音、快手为代表的短视频平台也快速的崛起，直播卖货为代表的新的销售渠道也深入人心。抖音、快手等各短视频平台也快速建设了相应的电商系统。直播卖货也成为了各公司新的销售渠道以及新的利润增长点。我公司在各大直播平台也有相应主播进行直播卖货。但是由于涉及的电商平台较多按传统的买家下单后公司需要到各电商后台去查询订单数据手动线下处理，这样严重的影响了发货退货等业务的时效，在这样的背景下为了适应新的业务发展和增强企业的竞争力，公司决定开新发一套新的电商系统。除了满足自营电商的需求外还需要全面打通与抖音、快手、天猫、京东、小程序等平台的数据流转。及协调后方销售、财务、工厂、库存中心、大数据中心等部门高效的进行数据交互。
微服务网关和注册中心区别
在这个项目中本人以系统架构师的职务加入其中，在接到项目后我们立刻对本项目进行了需求分析，系统设计。由于在电商潮汐期将会面临巨大的流量，系统还要接收来自各第三方平台的数据流量。电商系统将不定期举行抢购等活动，因此系统在高并发下的高可用提出了很高的要求，我和团队经过讨论后决定使用基于业务能力进行服务拆分的微服务架构方案。
在以往的企业系统架构中，我们针对一个复杂的业务需求通常使用对象或业务类型来建构一个单体项目。在项目中我们通常将需求分为三个主要部分：数据库、服务端处理、前端展现。在业务发展初期，由于所有的业务逻辑在一个应用中，开发、测试、部署都还是比较容易实现。但是，随着企业的发展，系统为了应对不同的业务需求会不断为该单体项目增加不同的业务模块；同时随着移动端设备的进步，前端展现模块已经不仅仅局限于web形式，这时系统后端向前端的支持需要更多的接口模块。应用由于面对的业务需求更为广泛，不断扩大的需求会使得单体应用变得越来越臃肿。单体应用的问题就逐渐凸显出来，由于单体系统部署在一个进程内，往往我们修改一个很小的功能，为了部署上线会影响其它功能的运行，并且单体应用中的这些功能模块的使用场景、并发量、消耗的资源类型都有不同，对于资源的利用又互相影响，这样使得我们对各个业务模块的系统容量很难给出较为准确的评估。所以，单体系统在初期虽然可以非常方便地进行开发和使用，但是随着系统的发展，维护成本也很变得越来越大且难以控制。
为了解决单体应用变得庞大臃肿之后产生的难以维护的问题，微服务架构诞生了，我们将系统中的不同
功能模块拆分成多个不同的服务，服务之间通过基于HTTP 的RESTful API进行通信协作。这些服务都能够独立部署和扩展，由于每个服务都运行在自己的进程内，在部署上有稳固的边界，这样每个服务的更新都不会影响其它服务的运行。同时由于是独立部署，我们可以准确地为每个服务评估性能容量，通过配合服务间的协作流程也可以更容易地发现系统的瓶颈位置，以及给出较为准备的系统级性能评估。同时由于有了轻量级的通讯协作基础，所以这些微服务可以部署在不同的操作系统上及使用不同的程序语言来实现。
微服务的好处很多，首先它很适合成为新技术的实验场，每个微服务是独立的，可以根据服务自身的需要采用合适的技术，如社交网络适合采用图数据库，结构化数据适合采用关系数据库存储，而非结构化可以采用Redis、MongoDB来存储。其它，微服务系统对外提供众多服务，系统的可组合性好，业务变化时能轻易组合服务实现，再次，微服务的可替代性强，可扩展性好，服务可以独立替换，每个服务可以内置自己的降级限流方案，可以独立扩展性能，方便调整系统的整体处理能力。微服务虽然有很多好处，但也有很多挑战，第一几乎所有的业务需求都要通过服务的编排组合来实现，服务之间的通信开销可能会影响性能，同时数据的一致性、可靠性可能受影响。第二运维成本高：运维人员需要维护的进程数量会大大的增加，有条不紊地将这些进行编排和组织起来不是一件容易的事，传统的运维人员往往很难适应这样的变化，我们需要运维人员的更多的技能来应对这样的挑战，运维的过程需要更多自动化。第三接口的一致性：虽然拆分了服务，但是业务逻辑上的依赖并不会消除，只是从单体应用中的代码依
赖变为了服务间的通信依赖。当我们对原有的接口进行一些修改，那么交互也需要协调这样的修改进行发布，以保证接口的正确调用，我们需要更完善的接口和版本管理，或是更严格的遵循开闭原则。第四分布式的复杂性：由于拆分后的各个微服务都是独立部署并运行在各自的进程内，它们只能通过通信进行协作，所以分布式环境的问题都将是微服务系统需要考虑的重要因素，比如网络延迟、分布式事务、异步消息等。
本系统决定采用基于J2EE的分布式微服务架构进行开发，系统使用当前比较成熟的Spring Cloud全家桶进行架设。Spring Cloud是一个基于Spring Boot 实现的微服务架构开发工具，它在微服务中涉及配置管理、服务治理、断路器、智能路由、微代理、控制总线、分布式会活和集状态管理等操作提供了一种开发方法。系统根据业务维度最终将系统分为销售中心、转单中心、结算中心、履约中心、数据中心、库存中心、退换货中心等核心业务服务模块。具体实施时使用Spring Cloud Config管理系统的配置信息，并使用公司内部的Git存储配置信息，各微服务客户端支持配置信息的刷新，加密解密配置内容。使用Eureka 微服务治理组件做为微服务的注册中心及服务的注册与发现。使用Hystirx微服务容错管理组件为微服务中出现的延迟和故障提供了强大的容错能力。使用Feign实现微服务间调用的负载均衡。及微服务网关Zuul为系统提供智能路由、访问过滤、接口权限控制等功能，同时每个服务内置超时处理和降级措施。由于系统是分布式部署的，我们使用Redis非关系弄数据库存储分布式会话信息及数据共享保证了各节点数据的一致性以及在系统促销时对数量进行控制等功能。订
单处理逻辑比较复杂，我们将系统不同的促销模块及转单中心独立做成微服务并根据流量弹性对微服务进行扩容，并将数据存储在独立的数据库中，然后通过Kafka异步的将数据同步到全订单库内。在微服务中单体应用的日志跟踪技术已经不能满足要求了，系统出现了异常很难去定位，因此我们采用了在Sleuth组件中集成Zipkin来实现分布式日志追踪，并将日志数据持久化在在ElasticSearch 中。搭建Jenkins工具链，测试Devops自动化部署，并配合容器化环境实现性能高效扩展。
最终经过我和团队的不懈努力，项目经过9个多月的开发测试并上线。系统稳定运行，由于使用了微服务架构，期间有用户需求需要修改系统可以快速的对某个服务进行修改而不影响整个系统。通过此项目本人认识架构师宽广视野的重要性，在以后的工作中，本人将为断学习，跟进技术的发展，为设计出更合适的架构贡献力量。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。