前言：
今年在新公司接触到了微服务和RPC的概念。我想从我着手的项目，再到公司的技术架构谈一谈我对微服务的理解。
我所认识的微服务
下面我详细的介绍下这里的过程。
- 制造thrift dataobject。
当需要一个对数据操作的业务时。我们要编写一个对外的thrift接口。
首先需要思考这个接口需要传递哪些参数，返回哪些参数，这些参数分别是什么数据类型（这和很多强类型的语言的感觉很类似）想清楚之后，就可以构建入参和出参的数据类型。当然thrift本身提供了一些比较简单的数据类型，如整形，字符型等等。在这些基础数据类型之上。构建出自己需要的入参或出参的数据类型。我称之为编写数据对象
下面举个例子
#入参对象
struct loginInput{
1:string username;#账号名
2:string password;#密码
}
#返回的用户对象
struct userobj{
1:i32 uid,#用户ID
2:string name,#用户名
3:string userface,#头像
}
- 制造thrift interface
我们知道，php，java都是有interface抽象接口概念的。接口中会有抽象方法，这些方法规定了方法名或者更多参数。集成类中需要实现这些抽象方法。这里制造interface就是这个概念
下面是例子
service UserService{
#通过账号密码获取用户信息
user.userobj GetUserInfo(1:user.loginInput);
}
这里构造GetUserInfo这个抽象方法，我们规定了他的入参和出参的数据类型。类型就是上我们定义的两个数据对象。只有按照这个规定的参数传递才不会报错
- 打包生成sdk
这里就不做演示了。总之神奇的地方就是这里。这里会有一个shell文件的方式来对我们之前定义的东西进行打包。打包出sdk，这个sdk是支持多语言的非常强大，下面看看百科是怎么说的
thrift是一个软件框架，用来进行可扩展且跨语言的服务的开发。它结合了功能强大的软件堆栈和代码生成引擎，以构建在 C++, Java, Go,Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 这些编程语言间无缝结合的、高效的服务
那么sdk有什么用呢？
这个不同的语言引入sdk的方式不一样。我就以php为例。可以使用composer来引入这个sdk。这个sdk里面包含了服务端和客户端所需要的东西。所以服务端和客户端都需要引入这个sdk
我们先从服务端说起。服务端引入了sdk后会得到3个东西。
- interface 文件（这个文件来源于之前写的规定入参出参的方法）
- 入参数据类
- 出参数据类
那么现在服务端就可以根据自己的业务去实现功能了。首先继承这个interface接口。实现我们设计的GetUserInfo这个方法。什么查数据库啊，模型啊，DB啊之类的就不介绍了。注意两个地方
1）入参对象上的数据。既然是编写服务端接口，那么入参里肯定是有我们需要的数据的。首先取出数据
2）出参对象。当我们把数据从数据库中查出来了之后，我们要按照出参对象上的属性来构建这个对象。然后一定要返回这个数据对象
那么现在所有的事情都做好了之后。在客户端又如何调用呢？
首先我们之前有提到过，客户端也要引入sdk。这个sdk中对每个服务都有一个类文件。这个类文件中就有调用某个方法的实现
示例如下。调用实际很简单。首先引入某个sdk，然后在自己的方法里构造入参对象。然后实例化接口类，调用接口类中的某个方法，然后就直接接收调用结果就完了。体验非常接近调用自己的一些service方法。只不过在这个调用背后其实是向外部进行了一次通信
感想
其实一开始，我认为这种方式来开发效率是真的底下。写个增删改查这种简单的东西都要花很多时间。不过站在一个企业，特别是大企业来说。这样做的好处还是很多的。
- 支持多语言（thrift支持很多语言，多语言之前无痛调用）。这样就可以避免因为语言问题去写重复的业务逻辑
- 项目解耦，比如多个项目都去调用一个服务端thrift接口。这个服务端查询数据库压力比较大。那么运维就去优化这一台服务器或集群就好了。而不用去关注每个不同的调用方的性能
3.由于sdk是已版本形式迭代。你写了一个新功能，你只需通知调用方，类名方法名和入参出参形式。调用方的程序员直接更新下sdk的版本就好了。这样更适合多人协助 - 调用规范。在客户端向服务端通信时。会自动校验，参数数据结构。调用来源是否合法等等。这意味着，每次从客户端传递的数据都是完整有效的。如果是参数不对或者来源不合法的话是不会请求到服务端的。这样也保证了服务端的性能不会被浪费，每次的请求都是有效且合法的。
尾巴
一个庞大的项目是难以维护的，再高级的程序员也难以维护超大的项目。将一个超大的项目拆分，各自独立建设会更利于项目的维护与开发。虽然在网络请求方面效率低了一点。却换来更灵活更健康的项目状态。微服务的概念已经被越来越多的公司所接受。我也是初次学习到这样的思想。如果有写的不对地方。希望能有大神指出，感激不尽谢谢
以上
