在当今世界, 人们几乎不可能脱离他人的服务, 一切自给自足地生活. 回想一下, 我们在超市购物, 在餐饮吃饭, 在公司上班, 解决客户的问题, 这些时候, 我们都在接受别人的服务, 同时也在为别人提供服务.
服务 Service 是什么? 简单来说, 服务就是为满足他人的需求所做的事情, 一个服务就是一个独立的功能单元, 比如上菜服务, 结帐服务, 泊车服务.
从软件开发的角度来说, 服务就是进程外的组件，它与其他组件以明确的接口进行交互, 就好象类似于进程内的函数调用. 从可读性, 可理解性, 可维护性的角度出发, 我们倾向于写小函数, 避免写过于复杂的大函数, 因为这样容易出错, 难于维护和修改. 若干功能明确, 职责单一的函数有利于重用, 提高开发效率.
同理, 服务也一样, 一个服务员既要上菜, 又要结账, 还要代客泊车, 这个服务员会很累, 很烦, 也很容易出错, 比较好的做法是不同的服务由不同的服务员提供, 各司其职, 一个人不要负责太多职责.
所以, 我们要提倡微服务 Micro Service, 意谓一种微小的服务, 崇尚小而美, 避免大而全.
是否采用微服务, 我们主要基于以下三点考虑
1. 分而治之以降低复杂性
软件行业一直在致力于降低复杂性, 人们想出来的方法大致都是分而治之, 要么纵向切-**分层**, 要么横向切-**分块**
分层
最有名的就是 OSI 的网络协议分层, 它有效地分离了复杂性, 下层为上层服务, 上层调用下层的接口, 在哪一层开发就只需关注哪一层的细节
| 层次 | PDU | 功能 | 应用示例 |
|---|---|---|---|
| 7. Application 应用层 | Data | 高层的API, 包括资源共享, 远程文件访问, 目录服务和虚拟终端 | DotNetFtpLibrary,[4] SMTP web API,[5] SSH.NET,[6] SnmpSharpNet,[7] HTML Class,[8] HTTP API server[9] |
| 6. Presentation 表示层 | Data | Translation of data between a networking service and an application; including character encoding, data compression and encryption/decryption | CSS, GIF, HTML, XML, JSON, S/MIME, |
| 5. Session 会话层 | Data | Managing communication sessions, i.e. continuous exchange of information in the form of multiple back-and-forth transmissions between two nodes | RPC, SCP, NFS, PAP,TLS, FTP,[10] HTTP,[11] HTTPS, SMTP,[12] SSH,[13] Telnet[14] |
| 4. Transport 传输层 | Segment (TCP) / Datagram (UDP) | Reliable transmission of data segments between points on a network, including segmentation, acknowledgement and multiplexing | NBF, TCP, UDP |
| 3. Network 网络层 | Packet | Structuring and managing a multi-node network, including addressing, routing and traffic control | AppleTalk, ICMP, IPsec, IPv4, IPv6 |
| 2. Data link 数据链路层 | Frame | Reliable transmission of data frames between two nodes connected by a physical layer | IEEE 802.2, L2TP, LLDP, MAC, PPP, ATM, MPLS |
| 1. Physical 物理层 | Bit | Transmission and reception of raw bit streams over a physical medium | DOCSIS, DSL, Ethernet physical layer, ISDN, USB |
( 参见 https://en.wikipedia.org/wiki/OSI_model )
企业中也是如此, 总经理, 部门经理, 组长, 再到一般组员, 下层只需向其上一层负责, 上层也只需向其下一层分派任务
应用程序中最典型的分层如下, 也可再做细分
| 序号 | 层次 | 职责 |
|---|---|---|
| 1 | UI/API 层 | 负责与用户或外界的交互 |
| 2 | 业务逻辑层 | 负责业务逻辑的处理 |
| 3 | 数据访问层 | 负责数据的存取 |
微服务在整个应用可能位于不同层次, 但它自己是自成一体的, 自己本身内部会有一些层次划分
分块
分层的好处显而易见, 坏处则在于层次要是过多, 层次之间的通信成本加大, 复杂性贯穿于各层之间, 依赖性层层传递, 有一层出了问题, 整个服务就会出问题
所以现实生活中, 有的公司...[TBD]
SOA- Service Oriented Architecture 面向服务的架构已经出来好多年了, 一直不温不火, 其典型的SOAP, ESB 等等技术太复杂, 并未广泛应用. 但是它的思想是和微服务一脉相承的, 那就是各个服务提供统一的接口开放自己的服务, 通过服务之间的相互调用, 互连互通, 共同协作,一起实现相应的业务功能.
服务与服务之间是松耦合的, 应用程序可以根据需要自由组合这些服务
一个服务本身应该相对独立, 具有一定的自治性, 实现一个相对完整的功能或者提供独特的数据, 一个服务对于其他的服务尽量避免强依赖
微服务首先是一种服务, 其次它是微小粒度的, 它自成一体, 彼此之间相互独立又相互协作.
2. 分而用之以提高可重用性
共享和重用是软件行业得以成长壮大的秘诀之一, 罗马不是一天建成的, 今天的软件也不是每一行代码都是自己写的.
提高软件的可重用性需要适当的抽象, 封装, 提供简单的接口供多方调用. 调用的方法无非是进程内的还是进程间间的
进程内的调用可以函数调用或事件传递.
进程间的调用取决于进程间的通信方式: 管道, 信号, 共享存储 消息等等.
微服务有利于可重用, 它属于进程间的重用方式,与调用方可以位于一台服务器上,也可以位于不同地域.
因其粒度微小, 故可重用度高. 它通过对外提供统一的 API 接口给调用方.
Web Service 用得最多是的 HTTP RESTful 消息, 消息格式多为 JSON 或 XML.
其他类型的微服务也以其他方式提供不同类型的服务, 比如 基于 TCP 或UDP 的 SIP 消息, XMPP 消息, 以及二进制的PDU(Protocol Data Unit) 协议数据单元.
3. 分而做之以提高开发效率
现代的软件项目通常要由多人或多个团队协作完成, 如果彼此之间互相依赖, 联系过于紧密, 牵一发而动全身, 那么团队之间花在沟通讨论和集成测试上的时间就难以估量.
如果把一个大项目交由几个团队来做, 那么应该把功能相对完整和独立的一个或一组服务交由一个团队来开发, 团队之间定义好清晰的服务接口, 然后各自进行开发和部署, 只要服务的接口不改变, 完全可以做到独立的实现, 部署和升级
所以我们要强调服务要微小, 并且相对地独立自治, 是一个比较完整的功能单元, 服务内部高内聚, 服务之间低耦合