如何将单片机应用程序‘重构’至微服务中

单片机应用程序遍布于当今的各类业务中。这些使用传统IDE构建而成的应用程序易于开发和测试,起码在刚开始的时候便于部署和扩展。然而,它有一个最大的缺点,那就是:这一程序的规模只会变得愈发大型和复杂,而最终会成为一种对各企业来说极其复杂的代码,因而会阻碍这些企业快速有效地回应日益变化的业务需求和客户需求。

由于单片机应用程序是开发应用程序的一种为人熟知的方式,所以在某些情况下,特别是在应用程序开发的早期阶段,它们能起到一定的帮助作用。此外,单片机应用程序还将业务逻辑视作其核心,并通过定义服务、域对象和活动的模块来实现。数据库和消息传递组件,以及公开API或实施用户界面的网络组件会围绕业务逻辑这一核心与外相接。

然而,虽然开发人员以模块化方式构建了这些应用程序,但他们却将其部署为了单片机应用程序——例如,将Java应用程序打包为WAR文件,并将其部署于应用程序服务器上或打包为独立且可执行的JAR,亦或是将Rails和Node.js应用程序打包为目录层次结构。

在项目初期阶段,这种模式可以带来很多好处,但随着应用程序的发展和功能的增加,一切就会开始变得复杂且缺乏灵活性。而事实上,开发得越成功的应用程序反而会越难管理——包括对原始信息和逐行(一行接一行)添加代码的管理。

在这时,要想实现程序的连续交付是不可能的,而且单片机应用程序也需分解成更小的部分。另外,在大型单片机应用程序上单独进行回归测试可能需要很长时间——尤其是在您的流程中设有手动UI(用户界面)或笔测试要求时。事实上,对于开发人员(尤其是那些刚接触这一应用程序的新手)来说,从事与之相关的工作已经很难了,更别提要真正弄懂这种程序了。而修复错误和解决漏洞——甚至还有增加新功能所花费的时间都将会呈指数式增长。

实施这些操作在任何情况下都有可能会出现问题,但如今的公司却都需要能高效且有效地响应新客户的需求以及日益变化的市场动态。对于您的公司来说,如果对关键应用程序作出更改就如将远洋班轮掉头一样艰难的话,那您公司的市场竞争力将会受到严重影响。

因此,单片机应用程序可能会同时阻碍企业进行创新和获得成功:由于采用新的计算机语言或技术可能会带来挑战,而单片机应用程序也难以扩展,所以这就会减弱企业满足日益增长需求的能力。此外,随着DevOps、微服务和容器的普及,单片机应用程序也可能会阻碍企业雇佣想从事最新技术相关工作的新兴人才。

那么,各公司需要为之采取哪些措施呢?亚马逊、eBay和Netflix这些超大型公司就是使用微服务架构成功部署应用程序的绝佳例子。他们将应用程序拆分为一小组基于业务功能而相互关联的服务。每个服务实现一组不同的功能——实际上就是以迷你应用程序的身份提供服务,同时具备自己独立的业务逻辑、适配器甚至是数据库模式。各服务可以以不同的方式组合在一起,然后以新产品的形式推出。

现在是微服务的时代

虽然微服务并不是一个新兴概念,但是它所代表的理念在如今这个日益变化的商业环境中比之前任何时候都要重要。每个服务都有明确规定的界限,并通过某种API进行连接,这样就能强化模块化水平,从而使得个人服务的开发、测试和部署能更加快捷。此外,您的开发人员也可以获得服务更易于理解和维护这一好处。

微服务模型还能使开发人员团队更容易专注于单一服务,而不是整个单片机应用程序,而且也可以使他们不受任何用于构建原始单片机应用程序的技术的束缚,并选择最适合服务任务的技术和迭代时间表。同样地,每个服务也都有自己的数据库模式。虽然这与企业级数据模型的概念有所冲突,但却能使开发人员使用最符合服务需求的数据库类型(即著名的polyglot persistence架构)。

如果您认为微型服务模型可以帮助您管好让您头疼的公司数据的话,可以参考下列三点建议,从而帮助自己摆脱困境(或顺利继续进行):

1. 适可而止。(或者,不要使早已过于笨重的应用程序更繁重了):在实施新功能时,不要在单机片应用程序上添加更多的代码了。相反,您应将新的代码转换为一种独立的微服务。

2. 从后端分割至前端:对于大多数单片机应用程序而言,展示的逻辑与业务和数据访问逻辑(其中还包括充当接缝的API)之间是截然不同的。而沿着这条接缝对应用程序进行“分割”可以创建出两个较小的应用程序。

3. 将现有模块转换为独立的微服务:您每次提取模块并将其转换为服务时,单片机应用程序整体就会缩小。而一旦您已经转换了足够多的模块后,那单片机应用程序也就不再是一个问题了。

微服务并不完美,也并不是解决任何企业应用程序问题的治愈良药。但是,这一服务还是正帮助公司更好地调整他们的业务和IT需求,并驯服单片机应用程序这一“野兽”。

更多资讯内容:>>>土地短缺或造成香港数据中心市场的发展减缓

Leave a comment

电子邮件地址不会被公开。 必填项已用*标注