不写代码搞定微服务架构改造，我信了你的邪
Posted InfoQ
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了不写代码搞定微服务架构改造，我信了你的邪相关的知识，希望对你有一定的参考价值。
作者 | 蔡芳芳
自 2014 年 Martin Fowler 与 James Lewis 共同提出微服务的概念以来，它就吸引了大批工程师和企业的关注，可以说是当前软件开发领域最火的技术热点之一。
在今年年初的一项云计算应用调研中，O'Reilly 调查了 1283 家公司，有 52％的公司表示他们正在使用微服务进行软件开发，其中超过 28％使用微服务超过 3 年，超过 55％使用微服务的时间为 1-3 年。O'Reilly 还指出，企业对微服务的兴趣可能达到或接近顶峰。
相比传统“大而全”的单体架构，微服务架构在故障隔离、整体可用性、架构持续演进难度、可重用性、可扩展性和交付速度等方面有突出的优势。
传统行业的系统架构大多是单体架构，随着业务规模不断扩大、代码量的膨胀和团队成员增多，传统单体式架构的弊端会逐渐凸显：代码冲突加剧、模块耦合严重，一次上线涉及人员太多代码质量无法保证、协作效率低下，每次开发测试花费时间过长、动不动几周甚至几个月……对于这些企业来说，微服务架构已经成为刚需，但真正要进行改造和部署时又往往无从下手。
有些人可能认为选好框架、把系统内部接口调用换成 RPC 或者 Rest 调用，就算完成微服务改造了，其实这只是微服务的冰山一角。
微服务改造的第一步是对业务进行拆分。服务拆分是否合理直接关系到微服务架构的复杂性、稳定性以及可扩展性，也是目前业内关于微服务议论最多、吵架最多的问题。不过当前业内也并没有统一的做法或规范，各家基本是根据架构师经验、业务形态和用户规模等因素综合考虑拆分粒度。
服务拆分之后需要做微服务的分层：梳理和抽取核心应用、公共应用，作为独立的服务下沉到核心和公共能力层，形成稳定的服务中心，使前端应用能更快速地响应多变的市场需求。
微服务的关键，除了跟服务设计本身相关的业务拆分和分层，还涉及微服务底层基础系统的构建工作。系统需要提供一套基础的架构，使得微服务可以独立的部署、运行、升级，同时让所有服务在功能上表现为一个统一的整体。这些系统性功能也需要有一系列服务来提供，它们可以视作微服务系统的“底座”。
一个完整的微服务系统底座最少要包含以下功能：日志和审计、监控和告警、消息总线、注册发现、负载均衡、部署和升级、事件调度、资源管理。另外还有一些非必须的底座功能：认证和鉴权、统一服务构建和打包、统一服务测试、微服务 CI/CD 流水线、服务依赖关系管理、统一问题跟踪调试框架、灰度发布、蓝绿部署等。
这个微服务底座必不可少，但实现起来工作量巨大。虽然业内已有不少可用于微服务架构落地的开源框架，但也并非拿来即用，而是有一定技术门槛，需要开发团队有足够的技术积累和实践经验，否则可能需要走很多弯路。以 Java 领域的微服务架构落地开源框架 SpringCloud 为例，光是组件就有数十个，并非所有开发人员都能很容易地全盘掌握这些组件的原理和使用。
此外，微服务架构本身也存在一些弊端。服务拆分之后，虽然单个服务代码量变小了，更易于修改和维护，但服务的个数变多了，系统总体代码量可能并不会减少，甚至更为复杂，对运维挑战很大。如果需要采用微服务架构的项目不止一个，而是几十个，难道所有项目都要让团队从头写一遍代码？经过实际业务验证的微服务组件能不能复用到其他项目上？如何保障所有服务的代码规范和质量？
上述这些，都是 2016 年底摆在陈定玮团队面前的问题。彼时的陈定玮正陷于 150 人研发团队的管理工作和永远也做不完的 CodeReview 中难以脱身。微服务的兴起是机会也是挑战，他开始思考一个问题：能不能用不需要写代码的方式来实现微服务架构的开发，进一步缓解研发项目管理的压力？
在陈定玮看来，软件工程行业虽然发展欣欣向荣，但实际上仍过度依赖“人工”，这也导致行业内普遍存在四大痛点：
项目成本高：人力成本高、沟通成本高、运维成本高、软硬件投入成本高；
开发周期长：开发者需要根据业务发展规模预期，配置相应的架构，不同架构的复杂度和开发工作量完全不可类比；
代码质量低：虽然业内有不少编码规范，但真正能遵守的仍是少数，而微服务架构下每个服务由不同开发人员开发，代码可读性、可维护性、重复度及可测试性都难以保证；
团队管理难：人才招聘难（符合要求的工程师难招，或者太贵）、人才管理难（大型软件开发公司或者国企、大型单位的 IT 部门人员过多）、技术资产保全难（员工离职后代码维护难）、技术依赖强（技术选型难、技术绑架多、技术趟坑多、技术沉淀难）。
2016 年，陈定玮团队从传统领域转型到互联网，研发团队从四五十人一下暴增到了 150 人，所有管理问题接踵而来。2016 年底，“不堪重负”的陈定玮开始反思软件工程体系管理的问题，并尝试制定解决方案。他希望将软件行业传统的“人工治理”的作业方式变成“法治”，告别代码，用标准化的流程操作和拖拉拽的方式实现开发。
对于软件开发人员来说，这是一个最终可能会“干掉自己”的项目，因此在一开始就引来了技术团队的不理解与抵触。最开始的时候，陈定玮只能单打独斗，同时不断给开发人员做思想工作。他希望工程师们可以从反复写代码、改代码的困境中解放出来，摆脱低创新、纯执行、重复性极高的代码编写工作，去思考、突破更高层次的技术问题。
虽然经历了无数质疑、不理解、争吵，但在董事长“没有预算限制”的信任与支持之下，陈定玮还是咬牙扛了过来。平台最主要的核心技术是用可视化的流程引擎代替代码来描述整个业务逻辑实现，运行时解析流程图执行，其中最大的难点就在于如何将流程图编译成微服务。陈定玮自己做技术调研和优化调整，攻克了这个技术难关。在魔鬼般的工作强度下，总算做出了一些可以“看见”的成果使人信服，虽然付出的代价是在项目初期长达一年的时间里完全没有“生活”可言。
当项目进入到第二个里程碑、平台初具雏形，加入这一项目的开发人员已经从 3 个人变成了 8 个人，说多不多，但都是精兵强将。
这个时候的平台其实还存在不少问题，在陈定玮看来，“没有经过实际生产环境实践验证的微服务架构都是耍流氓”，为了保障实际上线的效果和可用性，他开始“强迫”自己的团队在实际项目中使用这个平台。每来一个项目，就单独剥离一个团队使用这个平台做开发，第二个团队用传统的开发模式去交付，两个团队的工作同步进行。后者产出的 App 先交付给客户，服务升级时再将用平台开发出来的版本替换掉原来的版本。就这样通过一个个实际项目将平台锤炼得越来越好，下一步再给到不懂代码的业务人员试用，并改进界面功能和用户体验。
历经四年时间，飞算全自动软件工程平台总算顺利上线，这个最初看上去遥不可及的想法终于变成一个可以在生产环境大规模使用的产品。
在陈定玮团队中，大部分项目都已经改用这个平台来开发，为陈定玮有效缓解了项目和团队管理的压力。在公司科技项目数量越接越多、规模越接越大的情况下，公司技术团队却由 2016 年的 150 人，减少到了 50 人左右。陈定玮预计，“到今年年底的时候，公司技术团队二三十人就够了。”
飞算全自动软件工程平台涵盖“项目管理”、“自动化开发”、“自动化测试”、“质量管理”和“自动化运维”等五大核心板块，可以通过平台管理从需求、研发、测试、部署、上线到运维的整个软件生命周期。借助该平台，从项目经理到产品经理、部分架构师可以直接完成项目的计划和设计，不需要对研发工程师做任务分解和沟通；只要明确项目需求并设计好架构，就可以通过绘制流程图实现全自动开发；自带服务注册中心、分布式链路追踪、服务发现、服务治理等能力。
飞算全自动软件工程平台解决软件工程从项目启动到运维的 151 个问题
目前飞算全自动软件工程平台已经上线阿里云并对外提供 SaaS 服务。“自动化开发”板块率先发布，“自动化测试”和“自动化运维”板块的开发进度也已经完成 50%，会在不久的将来上线。
据陈定玮介绍，这次发布的“自动化开发”板块对标传统开发工具（如 Eclipse、IntelliJ IDEA），创新点在于用流程图取代了传统的代码编写，用户可以可视化地设计业务，只专注于业务逻辑，对使用者的专业领域、技术能力基本没有限制。
该平台提供了一系列标准化组件（包括基础组件、SQL 组件、工具组件等）、行业组件、安全模块等，这些组件和模块的开发代码只有在经过内置的代码质量平台审核通过后才能上线，可以有效规避传统编码方式难以保证代码质量的问题。
自动化开发平台界面演示
此外，平台自动提供内建的微服务能力，基于用户绘制的流程图，平台就能自动生成经过实践验证的微服务架构，用户下载项目部署包 + 执行服务包，放到服务端部署即可。用户不需要深入研究微服务框架，也不会陷入各类问题难以定位和解决的窘境。平台采用经过团队实际项目历练和验证的微服务最佳实践，在高并发、大业务量场景下的稳定性会优于用户自己使用的微服务框架。陈定玮指出，“虽然没办法跟阿里那么大的业务体量相比，但是足以支撑大部分中大型电商的业务体量。”
内建微服务能力也是飞算全自动软件工程平台与目前市面上已有的无代码、低代码开发平台最大的区别。陈定玮表示，飞算全自动软件工程平台目前在市面上还没有完全对等的竞争产品，市面上已有的产品均更偏向前端开发，而飞算全自动软件工程平台属于后端微服务开发。
表 1：传统开发产品 VS 飞算全自动软件工程平台
为了让大家能更直观地了解使用飞算全自动软件工程平台开发的效率与效能，在本周的发布会上专门设置了一个非常有趣的 PK 环节：基于同一份项目需求，开发人员手动编写代码和业务人员使用平台开发来比拼看谁开发的更快。
对于这样一个并不复杂的项目需求，一个业务人员使用飞算全自动软件开发平台开发只需要 20 分钟就能搞定，而开发人员用传统编码方式开发需要 1-2 天时间才能完成，开发效率提升数十倍。如果是更复杂的项目，开发效率的提升会更加明显。
微服务虽好，却并非银弹。随着云原生技术的推广和大量微服务案例的落地，社区关于微服务模式质疑的声音越来越多。陈定玮也注意到了这一现象，他表示，如果是企业内部使用的简单系统，可能确实不需要用到微服务，但对于有高并发、高可用、快速开发要求的场景，微服务依然是当前最好的解决方案，暂时没有第二种选择。当前很多有数字化转型需求的传统企业，都希望能吸引大量 C 端客户到自己的平台上，将公域流量转为私域流量，如果没有微服务体系的支撑就很难做到。
飞算全自动软件工程平台主要的目标用户群体也是这些真正有痛点的中小型软件公司和传统企业，这些公司通常有微服务改造的刚需，但受制于团队和技术能力无法实现。飞算全自动软件工程平台就是要帮助这些真正对微服务有需求却不知道怎么玩转的企业或团队，低成本快速上手。对于领域和行业，平台并没有任何限制。陈定玮强调，“只要是 Java 能做的，我们的平台都可以做。除了驱动、游戏、操作系统，基本上目前的应用系统都可以通过我们的平台来实现。”
技术层面，飞算全自动软件工程平台接下来主要有两项改进计划：一是支持标准的前端页面模板或者完全自定义页面、通过拖拽的方式实现前端页面开发，二是完成“自动化测试”和“自动化运维”板块的开发。
市场层面，陈定玮也提出了自己的愿景：三年内帮助 10000 家企业。在平台正式上线之前，已经有十几家公司在试用并基于平台构建项目。他还有一个更大的目标，就是要通过知识经验管理的贡献，彻底改变软件工程行业现有的作业方式，实现软件工程的全流程自动化。
至于目标能否实现，就要接受市场的考验了。陈定玮表示，从传统的编写代码做开发，到设计流程图做开发，对开发方式是一次很大的变革，原来用传统开发方法做过的东西需要全部推倒重来，这是平台推广的一个难点。如何让企业和开发团队接受新方式、掌握流程图设计，更重前期培训，接下来飞算全自动软件工程平台研发团队会专门组建一支培训团队，辅导用户更快上手使用。
陈定玮也提到，飞算全自动软件工程平台主要是帮助大家提高开发和维护效率、降低技术门槛，但是坦率讲，它并不能包办一切，无法帮助大家完成设计方面的工作，比如微服务拆分、数据库表设计等工作，但会提供培训和专业开发人员来协助用户做好这些工作。这其实已经属于互联网软件体系设计思路分享的范畴，也是需要教育的。玩转互联网软件体系的方法与传统软件的设计思维方式并不相同，陈定玮希望传达这样一个理念，也会将这一工作作为未来的重点之一。
点个在看少个 bug 以上是关于不写代码搞定微服务架构改造，我信了你的邪的主要内容，如果未能解决你的问题，请参考以下文章