2018-07-31
1，程序没有用适合的语言开发，程序效率低下，比如现在需要开发内存的缓存系统，但团队开发语言是java，java是一门高级语言，适合做业务系统，用java做内存操作内存会效率低下，而且浪费严重
2，开发框架和开发语言，都是有场景限制的，尺有所短，寸有所长这个道理在哪里都是一样的，c的优势在底层，java在应用，每一个都有所长所短
解决方案
1，将业务服务化，对外提供统一的API，各业务通过API调用完成，这样每一个业务都可以使用不同的开发语言和框架完成，各系统完全解耦。
2，容器化，使用docker将平台统一化，更好的可维护和扩展展开作者回复: 分析到位👍
24
2018-07-31问题就是可能发生“手里有锤子后，看到什么都是钉子”的情况，在业务规模小的时候采用单一语言单一框架，当规模大了还是应该有一定的灵活性，有一个主力的语言和框架，合适的工作用合适语言和框架，而微服务架构的比较适合混合语言和架构的模式作者回复: 赞同👍
14
2018-09-28如同没有包治百病的神药一样，每一个开发框架和语言也只能能解决某些场景，适合某些情况。
在公司中一方面会选择一个可以适应于大多数场景的主流的开发框架和语言，保证工作效率、人才体系和技术积累；同时也会根据特定场景选择其他的开发框架或语言，而后通过开发client包或采用约定协议的方式将异构的系统链接到一起，共同为业务服务。作者回复: 赞同👍
5
2018-08-26出现的问题：
1、违背了合适原则，本来用C++语言最合适，偏偏使用了Java
2、容易出现思维盲区，有可能有更好的替代品
解决问题：具体问题具体分析，规范是也是需要不断完善的，不能盲目遵守。作者回复: 赞同👍
4
2018-11-15老师，我记得SOA和微服务的章节说，SOA相当于多合一，将拆出来的各服务用EJB总线连接起来，这也是微服务架构和SOA的区别，那微服务的服务中心和EJB总线有什么区别呢作者回复: 你可以这样理解：EJB=所有微服务基础设施的全集
2
2018-08-10怎么保证消息队列的可靠性呢，万一消息队列集群挂了怎么做到消息不丢失？我想到的方案是发布消息之前先将消息表保存到数据库，消费方通过接口等方式变更消息表状态，服务定期检查消息表状态，将被未经处理的消息重发。帮我看下这样可行吗？谢谢：）作者回复: 发之前缓存，可以记录到本地，也可以记录到数据库，但这个方案的复杂度比较高，且建议只有发送失败的时候这样做，但其实还是没有保证完全不丢失，因为也可能发送到消息系统后消息系统挂了
1- 2018-08-09李老师，服务总线系统，就是企业ESB吧？对于大型金融类企业来说，服务总线系统更合适吧？服务名字系统每台机器都要拉取一大堆服务配置信息，配置信息更新也不够及时。请问阿里用的是哪种呢？
作者回复: 1. SOA架构就是ESB，互联网就是微服务的服务中心。
2. 服务名字系统确实需要拉取服务配置信息，但对于机器来说，几万条信息完全没有压力，所以不要担心。
3. 配置更新要及时的话，有几种做法：配置推送，配置定时（例如每秒）校验，zk配置变更通知。用得最多的反而是定时校验，校验做的很轻量级，每次只要校验配置版本号或者配置hash值 1 
2018-07-31今天介绍的内容是围绕着为服务架构所必须的几个组件，后续是否会详细介绍每个组件的设计原理呢。
使用统一的语言可能会限制实现功能的想象力和方案的选型和实现，拿着锤子，看什么都是钉子。
要实现多语言开发可以通信，可以使用规范的协议，而非语言特性。如restfull，自定义协议等。作者回复: 每个组件设计原理合起来可以开另外一个专栏了，本篇只是提炼重点内容
1- 2019-10-11技术上，不存在一个包打天下的框架。在业务发展的过程中总会遇到框架不适合解决的场景，如果死守原有的框架削足适履必然会带来不利的影响:开发效率低、工作量大、系统不稳定等；
管理上，团队中总会存在对技术有追求的员工，应鼓励这些员工引入新框架，有利于员工的职业发展，有利于团队的稳定，有利于营造较好的技术氛围；
战略上，框架一旦受限将是灾难性的。特别是大公司必须考虑框架受限时如何生存的问题。最近M国将H公司列入实体名单的事件相信给每个大公司提了个醒，要有备胎。 - 2019-10-10李老师，请教个关于协程与线程的疑问。比如，a协程调用socket. read(),此时数据没有准备好，则继续调度b协程。
把协程换成线程，上面这个过程哪个更加轻量？协程还是线程？
我理解这个过程涉及的过程如下，都一样。
1.都有系统调用read()，从用户态切换到了内核态，
2.都有上下文切换。(不同协程的寄存器，和不同线程的寄存器)
3. 都要执行任务调度。协程调度或者线程调度。
那协程到底轻量在哪？展开作者回复: 协程是用户态判断，不会切换到内核态，没有上下文切换
2019-10-08springCloud，算是服务名字系统吗？作者回复: 这个是微服务全家桶，里面什么都有
2019-09-29语言都有使用的场景，一种语言不能胜任所有的开发场景。
2019-09-04课后思考及问题
1：这节不费脑，使用统一的开发框架和开发语言可以让团队开发效率更高，但这样做会带来什么问题？
大一统是为了沟通交流管理方便，提高工作效率，提升团队凝聚力。
带来的问题，如下：
1-1：限制了某些场景使用更加合适工具的选择，这是最核心的，选择大于努力，选择错误越努力越费劲
1-2：语言和框架都有其存在特点，针对某些场景都有其功能优势，架构三原则，合适第一
1-3：使用某些场景强行使用不合适的语言或框架，会适得其反，不但效率不高可能会更低下
1-4：其实就像一国之兵种，海、陆、空在不同的战场有不同的优势展开
2019-08-181 随着时间积累，切换语言的风险越来越大。
2 缺乏技术创造力，不同的语言有其不同的适合场景
2019-04-21小公司的话肯定使用统一开发框架以及语言，效率最大化而且更容易管理掌控，在当前的业务场景下能够满足要求，但是当业务规模以及复杂度上来的时候，统一的框架以及语言会带来局限性就会非常明显，可选范围非常局限，所以这时候需要考结合务场景的要求，来选择合适自己的框架以及开发语言，往多元化进行考虑。
2019-04-19使用统一语言和框架，很可能限制技术人员的技术视野。一遇到问题下意识地想在这个框架或语言里我需要怎么解决。实际上可能有更合适的其他方案，对于一些细枝末节可以妥协，但是对于一些核心技术方案，则需要再做商议
第二就是整个技术团队更换框架的时候可能会因为步骤不一致导致一些团队沟通问题
2019-04-14服务总线系统相比服务名字系统虽然有诸多优点，但是性能可能会略差，而且服务名字系统的sdk一般放在上层公共镜像中，所以也具备一定的通用性，不知道这样理解是否正确？作者回复: 服务总线系统可靠性存在风险，服务名字系统sdk是通用的
- 2018-12-17使用统一的开发框架和语言可以降低团队的沟通成本和学习成本，但不能因地制宜，不同的业务采用适合的技术去解决。
问题：
1.解决效果无法达到预期，如性能效果，如展示效果，比如java也可以做pc的应用程序，但界面效果和运行效果都无法媲美c，
解决方法：根据不同的业务场景，参考业界主流和自身的情况采取合适的方式实现（有点像废话），但目前做的业务系统上确实没有照搬主流，更多是依据自身的情况，如成本、人员情况。 
2018-11-21弱弱的问一句老师，只能php的能成为架构师吗？作者回复: 架构师是分级的，参考特别放送的内容，只会PHP会限制你的选择范围，因此要成为优秀的架构师，只会PHP不太够
- 2018-09-28每一个开发框架和语言都有适合自己的应用场景，