1.学习/操作
1.从目前已经公开的资料来看，分布式服务化架构思想实践最早的公司应该是亚马逊。
2. 亚马逊如何做分布式服务架构的，遇到了哪些问题，以及是如何解决的? 亚马逊 CEO 杰夫·贝索斯（Jeff Bezos）就向全公司颁布了下面的这几条架构规定. -- 所有团队的程序模块都要通过 Service Interface 方式将其数据与功能开放出来。 -- 团队间程序模块的信息通信，都要通过这些接口。除此之外没有其它的通信方式。其他形式一概不允许：不能直接链结别的程序（把--- 其他团队的程序当做动态链接库来链接），不能直接读取其他团队的数据库，不能使用共享内存模式，不能使用别人模块的后门，等等。唯一允许的通信方式是调用 Service Interface。 -- 任何技术都可以使用。比如：HTTP、CORBA、Pub/Sub、自定义的网络协议等。 -- 所有的 Service Interface，毫无例外，都必须从骨子里到表面上设计成能对外界开放的。也就是说，团队必须做好规划与设计，以便未来把接口开放给全世界的程序员，没有任何例外。 -- 不这样做的人会被炒鱿鱼。 备注: 这也应是 AWS（Amazon Web Service）出现的基因.
出现的问题: -- 一个线上故障的工单会在不同的服务和不同的团队中转过来转过去。 -- 每个团队都可能成为一个潜在的 DDoS 攻击者，除非每个服务都要做好配额和限流。 -- 监控和查错变得更为复杂。除非有非常强大的监控手段。 -- 服务发现和服务治理也变得非常复杂。
解决方法: -- 分布式服务的架构需要分布式的团队架构 -- 分布式服务查错不容易 -- 没有专职的测试人员，也没有专职的运维人员，开发人员做所有的事情。 -- 运维优先，崇尚简化和自动化 -- 内部服务和外部服务一致。
备注: 在进化的过程中，亚马逊遇到的问题很多，甚至还有很多几乎没有人会想到的非常生僻的东西，它都一一学习和总结了，而且都解决得很好.
3. 分布式系统中需要注意的问题 问题一：异构系统的不标准问题 问题二：系统架构中的服务依赖性问题 问题三：故障发生的概率更大 问题四：多层架构的运维复杂度更大
重点: 分工不是问题，问题是分工后的协作是否统一和规范。 而且构建分布式服务需要从组织，到软件工程，再到技术上的一次大的改造，需要比较长的时间来磨合和改进，并不断地总结教训和成功经验。
后续补充 ... |
2.补充
TBD |
3.问题
3.1 如果你在分布式系统架构方面，有其他想了解的话题和内容 网友评论 javaee 国内按技能分工还是主流，采用分布式服务所产生的问题的确很多。特别是对于电商，业务链条非常长，环环依赖，业务上的沟通协调、排查问题方面要花大把时间。毕竟是各管各的，基本上没谁能对整个业务和技术链条都了解清楚。即便有，那也解决不了全公司的问题。公司大了，在开发语言、通信协议、数据规范都会尽量统一，运维逐步自动化，可视化监控并定义关键指标，同时还需要全链路的监控，这一切看起来非常好。但对于一家从3、5个人发展到几百、上千甚至上万人的时候，谁又曾想公司能壮大如此。即便想到了，在那时候技术也不是重点不会换入那么多资源，那时也不一定能找到愿意加入的技术牛人。因此，在公司高速成长的过程中，技术往往是受不到足够重视的，老板也没那么懂。所以技术上肯定会是比较杂乱的，各种语言，各种协议，各种部署方式，种种的异构在后期想统一的时候肯定是非常困难的，这个标准化的过程对于大多数公司来说将会是持久战。
|
