服务化设计过程中所关注到的点

服务化的目的
1） 为了抽取可重用业务逻辑供各个异构系统、分布式系统使用。
2） 业务的重用性达到了维护工作量的减少及各个系统开发工作量的减少且让各个系统具有独立职责。
3） 区别jar依赖在于业务逻辑实现的依赖与接口抽象的依赖关系。

交互协议
1） webService
2） hessian
3） dubbo
4） http json
5） 协议只是一种约定；简单的服务可能只需要支持一种协议方式；接口服务面广的可能需要支持多种协议方式。

接口设计：入参模型与返回参数模型
1） 入参模型与返回参数模型设计思路上面最好一致。例如：如果入参是用Map那么返回参数最好也使用Map；达到设计的对称性。
2） 作为支持同一种语言的协议，我们一般都会选择自己设计的模型作为入参和出参模型。
3） 接口最小化原则
4） 查询与操作类接口分开
5） 不同稳定级别的业务接口分开

安全性与授权及监控机制；
1） 任何商业应用系统的安全性都是重要的。
2） 服务化系统的数据安全性评估。
3） 对于操作类的接口必然需要授权；有必要的情况下我们需要通过框架或者是业务接口来记录操作的相关信息记录。
4） 授权与认证带来的也是服务化的注册登记，为后续维护升级提供了一个需求方白名单。
5） 认证授权、监控最好是采用无缝接入，避免框架级的插件侵入到业务代码中；
6） 接口的日志监控很重要，保障服务的正常运作及稳定性；通过监控数据可以分析你的需求方调用频率；分析你的接口调用PV分布情况；性能调优点等等。

通用性、业务逻辑共用
1） 一个服务存在后，必然会衍生更多个性化差异的需求；如何提供个性化的服务？对接口的设计和服务的设计都是一种挑战；我们需要考虑代码通用性，考虑个性化，考虑开发工作量，考虑维护工作量，考虑代码可读性等等一系列原则。

服务接口与util的选择
1） 如果一个商业运作的业务必然是会变化的，但是也有其变化的频率；统一对于商业逻辑上面的一些规则也是有一直在发展的，有是固定死的；权衡提供服务还是util就应该依据这个变化性。
业务的变化性
1） 业务的变化性也带来了业务逻辑的复杂化发展，特别是在没有好的产品关系设计、产品自身规划的情况下；我们的业务逻辑也会越来越复杂。
2） 服务化接口如何能为这种变化性提供保障？如何保障这种个性化需求后对主干流程的质量？
业务流程化
站在领域模型角度来看业务组件化和业务服务化设计(领域驱动设计)
服务化的系统可用性与外部依赖关系
服务接口的高性能及缓存策略
服务接口与业务逻辑、业务组件的关系；
服务的发布策略与版本控制；（新老版本共存稳定性）


仅作为一个工作备注，后面再细化到各个点；