方法即服务 — 1. 思考

"服务器"后端开发

很长一段时间我们做Web开发，拖拉控件，aspx/Razor视图，<% ... %>/@{ ... }脚本，前后端强耦合，几乎没有独立的前端程序员这个岗位，每个后端都是全栈...

后来ajax出现了，为了更好的用户体验，开始使用了静态html+ajax的方式构建页面，前后端初步的分离了一些，但是没有完全适应前后分离的我们在ajax中输出大段大段的<div> ... </div>，然鹅当页面样式发生变化后，这些后端方法需要全部重写...

再后来出现了前端MVC/MVVM，微服务概念，WebApi，后端负责输出数据，前端负责构建页面，这些WebApi还可以在html页面和移动端app之前复用，看似前后端算是彻底分离了，但是还有没结束。

所有这些开发还是依赖于HTTP协议，HTTP本身是以TCP协议为基础的一种数据格式协议，当有人不满足HTTP协议的臃肿，繁琐和低效后，他们就想自己搞一套RPC协议，然后就出现了各种各样的RPC框架，Remoting、WCF、Thrift、Dubbo、GRPC...

但是由于HTTP的不可替代性，所以程序员们还是不得不熟悉一个个的RPC框架和Web框架...

不管服务器的 后端开发

所以我就在想，能不能不需要了解这些RPC或者Web框架，我只要写一个方法

Class UserManager
{
    User GetUser(int id);
}

其他人就可以用自己擅长的方式调用，跟我没啥关系；

如果你擅长Http， 那么你就用

GET http://xxx.com/api/usermanager/getuser?id=1 HTTP/1.1
Accept: text/json

你说你更爱POST？擅长JSON提交，返回值想要XML？可以可以。

POST http://xxx.com/api/usermanager/getuser HTTP/1.1
Accept: text/xml
Content-Type: application/json;charset=utf-8

{"id":"1"}

你说你擅长GRPC？没问题！

service UserManagerService{
  rpc GetUser (GetUserRequest) returns (GetUserResponse);
}

message GetUserRequest {
  int32 id = 1;
}

message GetUserResponse {
  string name = 1;
  int32 age = 2;
}

方法即服务

写一个方法，只要你愿意将它公开，那么它就是一个服务

至于它将以什么样式服务形式被公开或者被调用，那不是开发人员需要关心的事，开发人员应该把精力都集中在功能上，保证执行和数据的正确性。

我想设计一个这样的框架，我将它取名为MIS（Method Is Service）

未完待续……

相关

方法即服务 — 2. 解耦服务器宿主