一、两步走
一个系统无论视同开发还是运行时的资源，都无法满足业务的需求，服务化是我们架构演进的方向，不是为了服务化而去做服务化，是由业务发展的复杂度和发展的业务量驱动的架构进化，是为了满足更快速的支撑更大规模的更复杂业务规则的扩展性要求设计，所以，我们做第一步，垂直拆分。
各系统通过WebService或者Rest等方式集成，以前最流行的SOA实施方式，看起来解决了业务发展过程中存在的一些问题。
业务类型较少的情况下解决了部分运行时资源紧张和故障隔离问题，代码拆分出来，项目构建影响小。就是松耦合，独立演进等等。
在只有一只手可以数的清楚的业务类型下，这种可以说基本上解决了我们一些问题，但是，我们的业务发展太速度了，每一种类型的订单，基本上都离不开这些领域的数据的交互，但是业务规则变化多样。
如果按照原来的思路，继续不断的增加一些类型判断如if...else...也能满足我们的要求，但是到最后可能就是 四五十个if else，而且相互影响，每个规则都相似又不同，所以其实大家发现了，其实这个时候订单的组装业务的规则已经成了现在的主要矛盾。
设计的问题，加一层就能解决很多问题，这个时候其实我们就需要吧我们的一些公共的服务（订单域）抽象出来，变化的规则通过具体的服务组装和编排去解决。
这个其实远了，我想说的就是，业务拆分，SOA能解决一部分问题，但是也有缺点，没有统一的管理，调用链不知谁依赖了谁，可靠性，可用性等的监控得不到保障，所以，这时候我们进入了 服务化的第二阶段，服务治理。
通过合理的管理和监控，保证所有的调用有据可循，有序有章法。
基本上所有的分布式调用框架的思路都大同小异，注册中心：服务注册、审核、变更、发现。
1、服务提供者：暴露服务接口的服务提供方。
2、服务消费者：调用远程服务接口的服务消费方。
3、监控中心：统计服务的调用次数、时间、结果等。
服务消费者通用组件：根据配置下载指定服务的可用服务地址列表，并缓存在本地。响应服务地址列表变更通知，更新本地可用服务地址列表。提供到注册中心长连接的重连机制。
服务提供者通用组件：启动时根据注解自动扫描提供的服务详情，上传提供的服务地址列表到注册中心，内建了还有并发控制等功能，序列化是通用的jsong，http请求，主要是方便各系统的集成，还是由于业务的不断发展，需要不断拆分。
二、对于一些系统故障，或者流量异常怎么办？
通过设计合理的调用日志，出入参，发起方落地房，调用序列号，时长等，将日志发送到ELK平台，实施监控一些异常信息，在异常信息中也去封装调用序列号，能够对部分小范围的单点的故障现场起到快速定位的作用。
发现所依赖的服务挂了，如何处理，有可能会吧把整个容器拖挂，我们在框架中集成了 Hystrix 组件，当挂住的线程超过了一定的数量则会快速返回，从而达到降级的效果。
看起来这些服务治理的问题都搞定了，接下来该怎么走。
如果你的业务复杂度不再增长了，但是业务量增长了，或许我们就要针对单一功能的容量和性能等可靠性要求进行设计，可能这时候进行弹性资源分配，或者分库分表等设计就要入场了。
牺牲一小部分去换取更大规模的业务，这是值得的：
服务化的过程就是 拆分-》治理-》拆分，其实是一个不断迭代的过程，是随着业务发展和业务认知深度的发展而不断的拆分和治理的迭代。
原文链接：