为什么使用微服务，为什么使用Tars

本文章为专栏系列文章推荐进入专栏按顺序阅读

1.项目架构演变中的思考：

为何要使用微服务架构:

单一架构模式在项目初期的时候开发,测试,部署方便,但是随着项目逐步开发,项目工程会很大,最终项目的耦合性会非常高，维护和扩展会变得非常复杂。

1. 不适合敏捷开发，任何模块的漏洞修复都需要开发人员去梳理调用关系，修改后对其他模块的影响很难估量；
2. 项目模块越来越大对程序的执行效率影响非常大，新人员接手非常痛苦；
3. 任意模块的漏洞对项目整体的稳定性和安全性的威胁特别大；
4. 因为模块之间的依赖关系，需要技术升级会带来非常繁重的兼容性工作。

使用微服务的优点：

1. 服务的技术选型范围非常宽泛，可以自由选择最为熟悉的语言和技术来实现；
2. 服务是独立的可以独立开发测试，独立部署，灵活的切换，具有非常强的容错性；
3. 服务单独可以分布式部署和负载均衡，提高服务的高可用性。

微服务的缺点:

1. 同一物理服务器中的不同服务互相调用也要使用相应的协议调用，不会像单体应用一样直接调用；
2. 多数据库中的事务操作非常麻烦，容易出错；
3. 微服务的测试工作比较麻烦，这个要因不同的语言和不同的微服务解决方案而论；
4. 微服务在实践中一般部署在不止一台服务器上一般需要持续集成(CI/DI)工具。

综上所述如果你是团队架构师微服务会成为你架构生涯中必须面对的选择，当然不能一概而论，就算是当前有很多公司使用单体应用依旧能很好的应对公司业务。

2.微服务和rpc的关系

文章一开始我们本身是本着rpc去的但是我觉得来龙去脉必须了解下

微服务和rpc其实不是一个完全相等的东西。微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。

所以微服务是一种架构模式或者思想。在实现形式上如果我们把开发工作中司空见惯的restfull api按照单一应用划分也可以称得上是微服务。当然在微服务的解决方案中有使用restfull的方式实现的。

rpc的意思是远程过程调用。他是一种微服务的调用方式。其实他要达到的目的和我们发送一个请求调用restfull接口一样的。但是rpc从传输性能以及服务的调用和发现上都要优于restfull，所以我们需要rpc。rpc使你调用微服务的感受就像调用本地一个函数、一个对象或一个代码块一样（这个只有体验后才能感受到），其实你调用的整个过程就是rpc相关的协议帮你做了。

3.微服务框架如何选择

当前成熟的微服务框架使非常多的。比较著名的有gRpc，dubbo，thrift，brpc，tars等等。在我以往任职的公司里有使用过thrift和grpc的经历。

这么多rpc框架如何选择其实对于架构师来说是不小的难题。一般我们选择技术解决方案的时候需要考虑一下几点：

• 生态的成熟程度，就是你要用到的东西基本上都能找到相关的方案，这个非常重要
• 社区的成熟程度，再好的东西你一个人闭门造车也造不出好东西来，社区的成熟度决定了你遇到问题后有没有人一起交流解决。
• 稳定性，是比较成熟和稳定的技术
• 易用性，易用对于团队合作来说非常重要，人员能够快速上手直接提高了生产力

综合上边所说其实thrift和gRpc都是不错的选择，毕竟经历了那么久的积累和迭代。

4.选择tars的理由

今天要说的是tars，其实tars在腾讯内部有着大量的使用。
tars有着以下的优点：

• 提供界面化的服务治理工具，大家可以看文档中对于tars web的介绍
• 支持的语言非常全面，支持go、php、java、c++、nodejs、等等
• 使用起来非常简单，tars本身提供了比较完备的工具链，但是官方文档比较混乱
• 本身性能非常高
• 对于对象的序列化即支持tars协议也支持google的protobuf