从微服务出发,聊一聊软件架构

架构发展大致是从单体架构到SOA(面向服务架构), 再到微服务这样一个过程
【从微服务出发,聊一聊软件架构】就单体架构来讲, 项目耦合性强, 项目部署困难, 且迭代周期长 , 而到SOA架构, 项目基本构成是zookper+dooble这样的形式, 内部通信采用RPC的方式, 外部通信采用HTTP形式, 特点是易拆分, 项目组件化, 单个子项目迭代快速, 项目半完全解耦, 但对服务器负担较重, 故多采用zookper或者Redis集群的方式分担服务器压力, 而到微服务时代, 通信采用Rest HTTP形式, 虽然通信效率比RPC形式要低2到3倍.
而且, 远程调用往往是需要依赖接口或者存根的.
那么就会产生依赖. 比如dubbo, 发布以及消费 服务的时候都需要指定一个接口, 服务端接口变化(比如多了个方法,少了个方法), 客户端需要重新引用和更新依赖的接口jar包.否则可能会遇到序列化的问题.
再者, server端实现了 一个接口,发布出来服务. 这个接口有5个方法, 客户端只需要知道和调用其中的3个, 由于接口类的依赖. 在客户端至少编程的时候是能call 5个方法的.
传输耗时往往并不是最主要的. 是能容忍的.
比如假设用 rpc 传输用1ms. 用http传输用5ms 看起来差了5倍.
但是这个操作可能业务耗时100ms. 那么整体上来看, 性能损失是可以接受的.
更通俗的说,与把时间浪费在优化上相比, 消耗相对多的资源是不是更好一些.
引用之前同京东一位架构师所说, 程序员的时间是最之前, 一个月的工资可以买更多的服务器,其实对公司来说是节省成本的.

    推荐阅读