那些微服务和技术堆栈教我们的事

Ashish Sharma 在本文中将谈谈企业技术堆栈主流是如何一步步走向微服务架构的，并分享一些经验教训。

过去的技术堆栈如下图所示：

在应用层，我们有一个用Windows form和WPF编写的桌面客户端。应用与服务层对话，而服务层是完全用c#编写的SOA体系结构。这是我们（当时）唯一可以使用的语言。它们是通过WCF相互通信的单片有状态服务。我们使用SQL server作为后端存储。所有这些都在内部部署，这意味着我们的客户购买我们的软件并将其托管在自己的硬件上。

我在金融行业工作（股市准确），是公有云的后期采用者。这个行业不喜欢将数据放在公共云上的想法。我见过的客户会阻止与外部世界进行任何可能的通信，以防止数据泄漏。但随着技术的成熟，种心态已经发生了巨大的变化，公司开始欣赏公有云及其周围的安全性。大约在同一时间，我们的利益相关者也决定将产品放在云上。管理层并没有要求迁移现有系统，而是让我们有机会从头开始构建产品。当时公司里没有人真正知道如何进行云开发，我们最终得到了这样的技术堆栈：

我们的Angular SPA应用，在服务方面，唯一的主要区别是我们从单一的有状态C＃服务转移到通过rabbitMQ相互通信的单片无状态C＃服务。我们继续使用Sql server作为后端存储。

在某些时候，我们认为我们正在做的事情是行不通的。我们在错误修正和功能上的循环时间很慢，部署很痛苦，需要大量协调。大约在同一时间，微服务正在增加。我们听到Netflix/Google/EBay等公司就采用微服务如何改变其业务的事情。遵循这些主题，它可能最初是作为某个团队的实验开始的，但今天变成了主流开发实践。

现在的架构看起来像这样：

我们有数百种不同的µ-services用不同的语言编写,.netcore golang、节点和 python 是最受欢迎的选择,一切都被部署为码头工人的容器中。服务通过nginx或rabbitmq与每个服务通信。每个服务栈都有自己的CI/CD管道。我这里没有所有的组件，但我希望这能让我们对今天的情况有一个很好的了解。我们也有单片栈，这是可以的，只要没有积极的开发。任何时候我们发现需要触摸单片的时候，我们都试图把它分割成一个不错的服务。今天，我们在一天内部署了很多次(没有停机)，我们可以更快地迭代特性!在后台，我们使用SqlServer、 MySql 、DynamoDB和 redis 缓存，这取决于我们试图解决的问题。

我们有数百种不同的μ服务，用不同的语言编写，.netcore，golang，node和python等等都是非常受欢迎的选择，所有应用都被部署为 docker 容器、服务通过nginx或rabbitmq进行通信、每个服务堆栈都有自己的CI/CD管道……当然我们也有一些一体化架构应用，这些应用的开发并不频繁。其他一体化架构应用，我们会尽量将其拆分为微服务架构应用。到现在，我们已经可以在一天内多次部署（零停机时间）并快速迭代功能！在后端，我们使用SqlServer、MySql、DynamoDB和redis缓存，具体取决于我们要解决的问题。

经验和教训

Docker是必须的

这一点现在已经很明显了，但是对于我们来说这是一个很有趣的问题，因为我们在.net c#堆栈上花费了大量的时间，而.net C#在很长一段时间内是不兼容的。在没有docker的情况下，我们需要处理的开销太多了，而docker周围的社区非常致力于消除所有的痛苦，好在今年的dockercon上Docker宣布完全支持windows。总的来说，Docker简化了交付、测试和开发人员体验。

允许团队灵活选择语言/技术堆栈

为什么要允许团队灵活选择语言和技术堆栈？因为他们是最接近问题的人，对如何解决问题有更好的想法。不仅从业务逻辑的角度来看，还有他们想要用来解决问题的 工具 和技术。如果无法实现完全的灵活性，至少可以列出堆栈选择范围。一切都是C＃或 Java 的日子已经一去不复返了。作为领导者/经理可以指导他们做出这个决定，但不要为他们做出这个决定。我们希望团队完全掌控他们正在生产的东西，不仅仅是业务逻辑，还有完整的服务。

不要创建服务框架并强制团队使用它

当我们开始云端开发时，往往以相同的企业思维方式接近它。我们创建了一个框架团队，负责编写一个框架来解决所有框架问题，因此其他产品团队不必担心它，他们可以专注于业务逻辑。一个问题是我们为每个人创造了二进制依赖问题。产品团队需要框架二进制文件才能运行其服务。他们遵循相同的模式意味着当他们需要来自其他产品团队的东西时，他们通过共享二进制文件来做到这一点。

我们必须以艰难的方式学习这一点。那么现在发生了什么？更好的新兴模式是团队创建服务模板并与其他团队共享。通常，团队拥有两三种不同语言的专业知识，并且他们不断构建新服务，他们制作服务模板来让工作轻松一些。使用这些模板，他们几乎可以立即启动新服务，然后与其他团队共享。现在，当我需要用到一种新语言，首先都会找到已经拥有它的团队并查看他们拥有的模板。

交付设计

交付设计的问题很有趣。通常企业中的思维过程就是这样 - 团队有一个问题陈述 - >他们设计解决方案 - >构建它 - >最后以某种方式提供它。

在微服务架构世界中，这种思维过程是不同的。团队有一个问题陈述 - >首先考虑交付。为什么？因为交付对您的设计方式有很大影响。它可以帮助您更好地分解您的解决方案意义，让我们在问题陈述中说 - 如果有一些非常活跃的和一些不那么活跃的区域，那么您可能希望以这种方式分解您的设计并独立地交付和扩展它们。您不会在数据库中编写过多逻辑或参考任何可能会降低您自己的交付速度的依赖项。

总是存在生产缺陷和性能问题需要处理，如果团队设计了他们的交付解决方案，那么团队可以更快地做出反应。

关于Rainbond

当下，已经有很大一部分公司完成了单体架构向微服务架构的迁移改造，并在疲于应对大量微服务间通信问题时，开始考虑采用Service Mesh微服务架构作为服务与服务直接通信的透明化管理框架，以插件式的方式实现各种业务所需的高级管理功能。

而开源PaaS Rainbond 提供了开箱即用的Service Mesh微服务架构，部署在Rainbond上的应用原生即是Service Mesh微服务架构应用。

• Rainbond项目网站
• 试用Rainbond公有云
  
  * 注册或使用Demo账号/密码登录：rainbond-demo/rainbond-demo
• Github
• 码云
• 文档
• 微信群: 添加微信“zqg5258423”并接受邀请入群