软件架构搭建

最佳实践建议：

(1)程序模块都通过ServiceInterface方式将其数据与功能开放出来。

(2)程序模块之间的通信，必须通过接口进行，没有例外。

(3)任何技术都可以使用。如：HTTP、CORBA、Pub/Sub、自定义的网络协议等。

(4)所有的ServiceInterface，都设计成能对外界开放的，团队必须对此做好规划与设计，以便未来把接口对外开放，没有任何例外。

通常把系统分成四层：

基础层：我们的机器、网络和存储设备等;

平台层：我们的中间件层，Tomcat、MySQL、Redis、Kafka之类的软件；

应用层：我们的业务软件，如各种功能的服务。

接入层：接入用户请求的网关、负载均衡或是CDN、DNS等。

做好配置管理，分成三层：

底层和操作系统相关；

中间层和中间件相关；

顶层和业务应用相关；

底层和中间层不能让用户灵活修改的，只能让用户选择。如：操作系统的相关配置应该形成模板来让人选择，而不是让人来配置的。

对运维来说，要有一个统一的视图和管理，运维才不会被分裂开来，才能降低复杂度。一个统一的运维视图，能够知道一个服务调用是如何经过每一个服务和资源，才能让沟通更有效和定位故障才能更快速准确。

面临的挑战：

(1)一个线上故障会在不同的服务和不同的团队中转过来转过去的。

(2)每个团队都可能成为一个潜在的DDoS攻击者。

(3)监控和查错变得复杂了。

(4)服务发现和服务治理变得非常复杂。

应对挑战：

（1）分布式服务的架构需要分布式的团队架构。一个服务由一个小团队（不超过16个人）负责，从前端负责到数据，从需求分析负责到上线运维。按职责分工，而不是按技能分工。

（2）分布式服务查错不容易。从故障发生开始，大家都在签到并自查自己的系统。如果没问题，在线待命（standby），直到问题解决。

（3）自己写的代码自己维护，让其体会到写代码容易，维护代码复杂。那么，开发人员在做需求分析、做设计、编写代码、做工具时会考虑到软件的长期维护性。没有专职的测试人员，也没有专职的运维人员，开发人员做所有的事情。

（4）运维优先，崇尚简化和自动化。不断地对系统进行简化和自动化。

（5）内部服务和外部服务一致，好处是内部系统的服务随时都可以开放。

（6）安全方面、接口设计方面、运维方面、故障处理流程方面，内部系统都和外部系统一样对待。

总结

分布式服务架构是需要从组织到软件工程，再到技术上的一个大的改造，需要比较长的时间来磨合和改进，并不断地总结教训和成功经验。考虑到分布式系统框架日后的维护问题，团队必须对此做好规划与设计。