Principle
我不要自我重复
单一职责原则
提炼原则
最小化耦合关系
保持简单
最大化内聚性
不要开发你目前用不到的功能
隐藏实现细节
用最简单的方法让程序跑起来
笛米特法则
不要让我动脑子
避免过早优化
开放/封闭原则
代码复用
为维护者写程序
职责分离
最少意外原则
拥抱变化
微服务现在已经是各种互联网应用首选的云架构组件,无论是BAT还是 滴滴、美团 ,微服务都是重要的一环。
微服务架构按照功能和业务将应用程序分离成若干个部分,使各个部分之间松绑。
一个典型的简单微服务架构至少有UI层、网关层、反向代理、微服务集群、互操作性部分组成。
1. UI 层:即前端视觉层,包括 web 端网页、手机APP以及PC客户端。
2. 网关层:网关层类似我们家里用的路由器,可以将入站请求重定向到目标为服务,并将站内的微服务进行整合打包输出到站外。UI层一般会通过 HTTP/HTTPS 协议访问网关向公网暴露的接口。此外,网关还应该具有鉴权的功能。
3. 反向代理:反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给internet上请求连接的客户端,此时代理服务器对外就表现为一个服务器。通过在网络各处放置反向代理节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络,CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。
4. 微服务集群:根据需求不同,微服务集群中会包含至少1个微服务实例,通过负载平衡将请求分配到每个实例上。如果使用Docker容器服务,则微服务集群中至少包含一个Docker实例,配合负载平衡,我们可以动态的决定要启用多少个Docker实例,并在不需要的时候销毁冗余的实例,提供完全自动化的弹性计算能力。
5. 互操作性:微服务之间一般选用 HTTP/HTTPS 或者 RPC 作为互操作协议,使用JSON或者ProtoBuf序列化对象。由于微服务都部署在同一个内网之中,性能损耗几乎可以忽略不计,如果选用RPC + ProtoBuf 的交互方案,延迟会更低。