服务化、高可用

数据序列化：

开始设计一个服务化框架时，第一件重要的事情就是选定一个标准的数据序列化协议。序列化协议重点需要从扩展性，传输性能以及业界通用性（换句话说就是不同技术/语言的支持程度）三个因素里来协调选择。在这三个方面都做的比较好，也是使用最广泛的就是Json和Protobuf了，基于文本的Json在可读性和灵活性上占优，而基于二进制的Protobuf在传输性能生更胜一筹。

 

通讯协议选择

可以在基于HTTP或TCP链接上建立自己的通讯协议。比如可以设计一个简单的header（定长）+body（序列化的请求/响应）。如果采取json作序列化协议的情况下，可以跟我本次的选择一样，采取一个类似json-rpc, 完全基于json的通讯协议。

 

注册与授权管理

注册管理是解决系统交互复杂性的关键，当服务数量和服务使用者数量爆发性增长时，最难回答的问题就是“服务被谁使用了？”以及“有哪些服务可供使用？”，注册管理就是解决这两个问题的最佳方式与实践。

注册管理的实现上其实也很简单，提供一个Config Server（配置中心），收集服务提供者的注册信息（包括服务名称，服务地址（可以多个），版本，超时时间控制等），我们称为服务的元信息。而当服务使用者需要调用相应的服务时，就可以利用这些元信息来查找和调用相应的服务了。

在元信息的使用上，存在两者架构方式

1.服务使用者访问统一的服务中转器，由服务中转器按照注册信息以及负载情况将请求转发到相应的服务地址上。服务执行后，响应信息返回到服务中心，服务中心将响应回送给调用方。

 

这种方式的优点是能比较好的控制所有请求的调度。当服务元信息发生变化时，能及时地调整请求转发（负载）与超时控制等。缺点是请求和响应均需要由中转中心负责转发，性能耗费较大。同时，中转中心的可用性也容易产生问题，必须通过集群的方式来解决。

2.服务使用者负责从配置中心获取服务地址等信息，然后有由服务使用者直接向相对应地址上的服务发送请求，请求也直接由服务提供者返回给服务调用者。同时，服务使用者本身可以缓存一定的服务元信息，防止每次访问都要从配置中心获取，以降低配置中心的负载，增强整个系统的可用性。当配置中心的服务元信息发生变化时，通过通知的方式告知服务使用者更新本地缓存。

这种架构方式与第一种架构相比，能显著降低性能的损耗，以及服务使用者对中心节点的直接依赖。但代价是需要彻底改造服务使用者的调用方式，框架的代码必须侵入到客户端的开发中去。一般会针对不同的客户端提供clientLib，但当客户端实现方式多样化时，这种代价是非常大的。

3.路由与过载保护

 服务路由能将来自不同访问者请求或者不同的请求内容，分发到不同的服务提供区域去，路由功能可以用业界通用的负载均衡器比如Nginx实现。通用的负载均衡软件的问题是路由算法比较通用，当需要扩展到与业务逻辑相关的路由绑定时，比较麻烦，比如需要用户ID按权重分配路由。在此建议，可以采取通用的负载均衡软件当第一层接入，而在服务节点之间采取自己实现路由模块的方式。

过载保护功能保障提供服务提供者的业务系统不受“恶意”调用或突发性激增调用的破坏。过载保护越靠近服务访问前端越好。

4.服务拆分与组合化

大粒度服务拆分成模块级甚至是功能级的服务，缩小了服务粒度，为应用和服务的实现带来了更强的灵活性，服务交付周期也大大缩短了。但这样的细粒度拆分服务，使需要访问的服务数量大幅度增加。可以通过中间加一层来解决。我们可以将多个服务打包成一个新的服务提供出去。

 

5.基于配置的服务运行时提供

通过基于配置，由框架提供运行时，动态加载业务代码的方式。

做到这点，只需要约束业务逻辑代码实现相应的接口/基类，然后打包成相应的组件（如jar/dll/so等）提供给框架加载运行即可，类似于java servlet的开发，业务开发完全不用关心服务化框架任何功能，专注开发业务逻辑即可。同时，对于既有代码的服务化也将变得简单，只需要稍加重构封装出实现相应的接口即可。
 

6.服务化架构演进

orm – 单一应用架构：是一个高内聚版本，所有功能部署在一起。数据访问框架（orm）成为关键。这个架构很少被人使用，几乎接近灭绝了吧。  优点：成本低，适合功能少又简单 缺点：很多，比如无法适应高流量，二次开发难，部署成本高。

        mvc架构 － 垂直应用架构：当访问量渐渐增大，慢慢演化成用的很多的mvc架构。虽然还是所有的功能都是部署在同一个进程中，但是可以通过双机或者前置负载均衡来实现负载分流。这样应用也可以拆分成不同的几个应用，以提升性能和效率。此时，mvc架构用于分离前后端逻辑。一方面，有一定的模块化。另一方面，加速和方便了开发。

        rpc架构 － 分布式服务架构：当mvc垂直应用分成不同应用时，越来越多的情况下。不可避免的事应用a与应用b之间的交互。此时将核心和公共的 业务功能抽出来，作为单独的服务，并实现前后端逻辑分离。此时则就需要提高业务的复用及整合的分布式rpc框架。

        soa架构 － 流动计算架构：当rpc架构中的服务越来越多时，服务的生命周期的管控，容量的评估等各种问题会出现，使服务化成为瓶颈。需要增加一个调度中心来进行对服务管控，监督等。

       微服务架构：对于微服务，我们可以简单的理解成对一个服务解耦，以降低业务系统的复杂性，将服务系统中的功能进行拆分成多个轻量的子服务，各个自服务间通过RPC实现服务间的关联，这样做的好处是将业务简单化，每个子服务可以有自己独立的编程语言，模式等且能够独立维护，独立部署，功能复用。

 

高可用的架构

1.数据和服务的①冗余备份②失效转移：

　　对于服务而言，一旦某个服务器宕机，就将服务切换到其他可用的服务器上；

　　对于数据而言，如果某个磁盘损坏，就从备份的磁盘（事先就做好了数据的同步复制）读取数据。

2.高可用的数据

①数据备份：又分为冷备份和热备份，冷备份是定期复制，不能保证数据可用性。热备份又分为异步热备和同步热备，异步热备是指多份数据副本的写入操作异步完成，而同步方式则是指多份数据副本的写入操作同时完成

关系数据库的热备机制就是通常所说的主从同步机制，实践中通常使用读写分离的方法来访问Master和Slave数据库，也就是说写操作只访问Master库，读操作均访问Slave库。可以通过发布订阅功能实现主从分离。

②失效转移：若数据服务器集群中任何一台服务器宕机，那么应用程序针对这台服务器的所有读写操作都要重新路由到其他服务器，保证数据访问不会失败。

3.分层设计——各层面临的主要问题

接入层：主要流量入口，经过简单

1、dns被劫持：域名是否使用https。

2、黑客攻击：是否有弱密，服务器权限，数据库权限

3、ddos攻击：是否有必要使用高防IP接入流量。

4、CC攻击：免费和收费版域名分开，网关是否有限流和防刷措施。

应用层：直接对外提供产品功能，例如网站、API接口等。应用层不包含复杂的业务逻辑，只做呈现和转换。

1、应用服务器宕机。

2、应用服务bug。

3、第三方服务不可用。

服务层：根据业务领域每个子域单独一个服务，分而治之。

1、服务不可用或者出现bug。

2、第三方服务不可用。

数据层：数据库和NoSQL，文件存储等。

1、数据库服务器磁盘损坏导致数据库不可用等