1月，我司承接了一套虚拟运营商平台管理系统项目，进行架构升级与改造。系统主要包含号卡计费功能、号卡风控管理、财务对账管理、营销后台管理、实名认证功能、ISP交互系统以及支撑运营人员各种所需的常用功能等。我在该项目中担任技术负责人，主要负责针对系统的架构设计与考量。项目之前采用单体架构，各模块深度耦合不便于后期应用的扩展与可维护。首先，我们将模块拆分为粒度更小的微服务，服务职责更得加单一，利用Docker容器技术将微服务独立部署，提高了系统的可移植、扩展性。其次，我们利用微服务支持异构技术选型的特点，针对不同的微服务选用不同的技术方案来最大限度发挥其优势。最后，我们利用DevOps对系统开发进行持续集成与交付、提高了软件质量与开发效率。项目如期顺利上线，获得用户一致好评。
1月，我司承接了一套虚拟运营商管理平台系统项目，进行二次开发与改造。该项目面向的主要是虚拟运营商的运营工作人员与财务相关人员。该项目表现层采用B/S架构，前端和后端采用混合式PHP开发。服务层任然是传统的单体架构，所有的业务功能模块全部耦合集成在一套代码中。早期业务量少，没有暴露出十分严重的问题，但是随着公司业务量的极速发展，当前系统暴露出了许多致命问题。例如某个模块需要上线新功能，整个更新与迭代的过程都显得十分困难，牵一发动全身。如果稍有不慎线上产生错误，给公司照成较大的经济损失，同时也给开发人员造成了很大的工作压力。再例如系统的某个模块访问量和使用频率较高，在流量大的时候，我们其实想针对特定模块进行扩容操作来提升系统并发能力。但是，由于这些功能模块都是耦合在一起，就会照成一个局面，要么全部模块进行扩容，要么都不扩容。不能针对特定功能模块很好地进行弹性扩缩容，为了支撑业务，只能浪费不必要的成本来扩容达到目的。最后，系统在迁移时耗费大量的人力与物力，环境重新搭建配置，数据进行迁移，系统再进行对接等等流程。整个过程下来，对企业可谓是伤筋动骨，付出的工作量与产出不成正比。所以针对上述情况，甲方公司委托我司针对系统进行架构改造与升级，刻不容缓。我们综合项目情况与团队技术能力，最终选用微服务架构来实现对项目的改造与升级。
微服务是一种将业务功能模块进行更细粒度拆分、各服务能独立部署并且服务之间采用轻量级通信协议进行交互的一种架构。该架构相对单体架构有着明显的对比，具备以下几个特点:
1. 微服务与SOA架构类似，是SOA架构的一个变种。但微服务拆分服务的粒度相对SOA架构更小，每个微服务职责更加单一、设计简单。每个服务通常结合轻量级虚拟化技术例如Docker等进行独立部署，独立部署的好处就是服务之间运行环境隔离，不会相互影响。
2. 微服务由于可以获得独立运行部署的能力，具备服务技术异构性的特点。各微服务，我们可以选择更合适的技术选型，如开发语言、数据库的选型。这样可以最大限度地将合适的技术选型与场景进行结合，提高开发效率与软件质量。
3.微服务天然与DevOps持续交付、持续集成技术相结合。自动化运维开发，能够减轻开发人员的负担，减少人工参与重复且无意义的劳动。将开发人员解放出来，让其花费更多精力专注于业务开发。
4.微服务具备很强的容错能力、支持弹性伸缩。单个服务的出错，不会照成整个系统大面积瘫痪。针对特定微服务可以弹性扩容、缩容，不会造成资源浪费与成本开支。
综合以上论述的微服务特点，以本项目为例，我们利用到了微服务的部分特性对项目进行改造，阐述一下微服务的设计与应用过程。
一．微服务拆分与部署。
首先，我们需要针对业务功能模块进行界定划分。得到明确界限的功能模块后，再进行更细粒度的拆分，但是也不能拆分过细，综合评估划定好微服务职责范围，完成服务的拆分。每个服务只专注做一件事情，符合单一职责原则。之后，我们会针对服务编写Dockerfile，构建单个服务的运行环境镜像，后续服务的运行
、部署会变得及其简单。开发团队的每个成员都能在统一环境中运行程序，不会造成因运行环境不统一而导致各种奇怪的兼容性问题。单纯只是将服务拆分、环境部署等相关问题解决还没有结束，服务之间的治理同样重要。每个服务之间是如何发现彼此的存在?其中服务注册中心是不可或缺的组件，服务提供者需要注册到服务注册中心被服务调用者进行发现，我们采用Kubernetes分布式容器调度技术框架进行服务治理，每个微服务对应Kuernetes的Service
，服务之间直接通过内部DNS域名的方式进行统一访问而不必关心后服务后面负载均衡的情况，很好地完成了服务治理任务。服务的负载均衡与集群如何实现?Kuerbetes将微服务封装在Pod中作为基本调度单元，我们可以设置声明式规则，对微服务自动进行动态扩容和动态缩容，减少运维成本，提高系统的可靠性和稳定性。
二. 利用微服务支持异构技术选型，提高系统性能与开发效率。
其次，微服务支持技术异构性无疑也是相比于其它架构的一个亮点。往往我们在单体架构中，已经固定了例如开发语言的选型、数据库系统的选型、开发模式的选型等等。但是并没有什么单个技术选型是适合所有业务场景的，有些技术选型可以增加系统性能，但是降低了开发效率。但是微服务不一样，针对号卡计费服务，我们更专注于服务高性能，选用J2EE技术进行开发，提高了系统性能与稳定性。例如有些技术选型适合于小型系统，针对访问量不是太大，但是开发速度却很快。针对Web后台管理功能，如财务对账模块、营销后台管理，我们采用PHP进行后台管理开发最为合适。又如针对海量日志存储、日志检索的相关功能,大量的非结构化数据存储，我们更倾向于使NoSQL而非关系型数据库MySQL等.单体架构无法做到技术选型多样性的支持，鱼与熊掌不可兼得，只能权衡与一些妥协。但是，微服务很友好地支持技术异构性，我们可以结合自己本身服务关注的要点，选择更适合自己的开发语言、数据库类型等，最大限度地发挥技术选型的优势与业务功能的结合度，达到最大的开发产出比。同时，针对后期业务量剧增，技术团队多样化，技术栈也会变得多元化，微服务的这个特点会更加有所体现。每个团队专注维护自己的服务，做自己擅长的技术栈，发挥每个团队自己的特长。
三.结合DevOps技术，提高研发效率与质量。
最后，单体架构中功能模块深度耦合，不止开发新功能上线会面临压力，测试工作也会显得十分被动。有时候只是修改某功能模块局部代码，但是测试工作需要波及到其他模块。因为我们无法确保自己修改的局部功能是否会牵扯到其他功能。我们结合相关DevOps持续交付、持续集成技术，从代码的提交到Gitlab(版本库)开始，就在做一系列自动化测试、构建，例如程序的基本语法测试，配置自动化，完成持续交付过程。通过使用Jenkins持续集成工具，对项目进行编译、打包推送到测试环境、预上线环境执行预设自定义测试脚本，通过相关监控告警工具，监控整个开发集成进度与详情。遇到测试错误问题会得到及时反馈，开发人员进行错误修正。每次开发与验证、上线都减少人工干预，解放开发人员繁琐重复劳动的同时，也是对整个系统开发加以稳定性保障。
4月，历经15个月研发过程，项目如期顺利上线，获得甲方客户好评如潮。项目中我们也遇到了一些相对单体架构要解决的难题。微服务分布式的特性，导致原本单独的本地事务会造成分布式事务，增加了系统开发的难度。我们使用了基于MQ消息队列解决分布式事务的方案，兼顾了解决了事务问题与系统性能。针对微服务集群的复杂性，各种调试日志无法集中查询与定位，我们采用ELK日志采集技术与Grafana监控系统对整个微服务进行全面监控，便于开发与运维人员排查问题。我们在以后开发项目的过程中，要根据实际情况选择系统架构，并不是说单体架构一定是落后的，同时也不代表微服务能适应所有业务场景，只有合适的场景选择合适的架构才是最为明智的选择！
如果觉得《论微服务架构设计与应用》对你有帮助，请点赞、收藏，并留下你的观点哦！
