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

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”并接受邀请入群