微服务架构的概念

2019独角兽企业重金招聘Python工程师标准>>>

最近一段时间以来，社区中围绕着微服务产生了很多争论，也充斥着大量的宣传。过去的10年间，我们已经实现了很多笨重的SOA解决方案，微服务是业界期待已久的解决方案么？或者说微服务要比整体解决方案更加简单？

在讨论这些话题之前，我们最好先对微服务下个定义。在题为微服务的文章中，作者James Lewis与Martin Fowler是这样定义微服务架构风格的：

开发单个应用作为一系列小型服务的套件，其中每个服务都运行在自己的进程中，并且通过轻量级的机制实现彼此间的通信，这通常是HTTP资源API。这些服务是围绕着业务功能构建的，并且可以通过完全自动化的部署机制进行独立部署。这些服务的集中式管理做到了最小化，每一种服务都可以通过不同的编程语言进行编写，并且可以使用不同的数据存储技术。

微服务的一些优势是显而易见的：

• 每个服务都很简单，只关注于一个业务功能。
• 每个微服务可以由不同的团队独立开发。
• 微服务是松散耦合的。
• 微服务可以通过不同的编程语言与工具进行开发。

这些优势使得微服务看起来是非常完美的解决方案，不过微服务难道就没有缺点么？

运维成本过高

故障恢复后，20个服务可能要占据40——60个进程，同时弹性问题也浮现出来了。在添加了负载均衡与消息中间件后，进程的数量还会持续增加。运维与编排所有这些服务是个“令人望而却步的任务”，Wootton说到：

实现所有这些需求需要高质量的监控与运维基础设施。保持一台应用服务器的持续运行就需要专人来负责，但现在我们还得确保几十、甚至是几百个进程都处于运行状态、不能将磁盘空间耗尽、不能出现死锁，还要保证性能。这真是一个非常棘手的任务。

运维的过程需要自动化，不过由于“并没有多少框架和开源工具能够对此提供支持”，结果就是“使用微服务的团队要在他们编写具有业务价值的第一行代码前需要大量使用自定义脚本或是进行开发以管理这些进程”。

 

DevOps是必须的

Wootton认为实现微服务的组织需要DevOps，这是因为：

你不能简单地将通过这种风格构建的应用抛给运维团队。开发团队需要非常关注运维与产品，因为基于微服务的应用与其环境上下文是非常紧密地集成到了一起的。

由于很多服务可能都需要自己的数据存储，因此开发者还需要“搞清楚如何部署、运行、优化以及支持各种NoSQL产品”。

 

接口不匹配

服务依赖于彼此间的接口进行通信。改变一个服务的接口会对其他服务造成影响，Wootton谈到：

修改了契约一方的语法或是语义，那么所有其他服务都需要理解这个改变。在微服务环境下，这意味着简单的交叉改变会导致很多不同的组件发生变化，这些组件需要以一种协调一致的方式进行发布。 

当然了，我们可以通过向后兼容的方式避免这些变化的发生，不过实际情况却是业务驱动的需求让我们没法实现分阶段的发布。 

如果彼此协同的服务向前推进并且不再同步了，比如说使用canary发布方式，那么修改消息格式的效果就难以可视化了。

 

代码重复

为了避免将“同步耦合引入到系统中”，Wootton认为有时需要向不同服务添加一些代码，这就会导致代码重复，而代码重复“是非常不好的，因为每个代码实例都需要进行测试和维护”。一种解决方案是在服务间使用共享库，不过“在多语言环境下这就行不通了，而且引入了耦合就意味着服务需要并行发布来维护彼此间的隐式接口”。

 

测试

使用微服务架构时，测试是另一个需要考虑的问题，因为“无论是手工测试还是自动化测试，我们都很难以一致的方式重现环境”，Wootton说到：

当添加了异步与动态消息负载后，要测试以这种风格构建的系统就难上加难了，同时也无法对将要发布到生产的各种服务抱有信心。 

我们可以测试每个服务，不过在这种动态环境下，非常微妙的行为都会从服务间的交互中产生出来，这是难以做到可视化的，也不易想清楚，更不必说全面的测试了。

 转载请注明地址https://my.oschina.net/u/2286631/blog/edit/983195，谢谢。

 分布式事物的处理

作为一种分布式系统，微服务引入了复杂性和其他若干问题，比如说“事物,网络延迟、容错性、消息序列化、不可靠的网络、异步、版本化、应用层中的负载变化等等”。其中分布式事物是最难解决的难题之一,大家都知道本地事物局限性是单进程，单数据源，而且在并发下面效率很低。所以针对分布式的事物我们该如何去实现呢？本文会结合自身项目经历给大家进行一些分享。当然有什么漏洞的欢迎大家一起讨论。

 

/**
*   ————————如果觉得本博文还行，别忘了推荐一下哦，谢谢！
*   作者：写程序的奥特曼
*   欢迎转载，请保留此段声明。
*   出处：https://my.oschina.net/u/2286631/blog/edit/983195
*/

转载于:https://my.oschina.net/u/2286631/blog/983195