net分层架构设计
netconf协议分层设计有哪些优缺点？
netconf协议分层设计有哪些优缺点？
优点:
1. 改动方便：如果仅使用一个协议，那么当其中的某一部分发生改变的时候，就需要把整体全部替换掉。
2. 设计简单度：使用分层时候，仅需要替换改变的层的内容回，只需要把每层之间的接口部分定义规划好，那么各层内部就可以随意改变，更加灵活自由，在设计上答也简单很多。
缺点:
分层协议的缺点是层次划分得过于严密，以致不能越层调用下层所提供的服务，开销太大，降低了协议效率。
分层协议依据逻辑功能的需要来划分网络层次，每一层实现一个定义明确的功能集合，结构清晰，有利于理解学习，但是当网络设备增多，每增加一台设备就会增加一个故障点，没有考虑网络实际应用的复杂性。
资深Java架构师经验之谈，项目的”烂”和”好”如何衡量和定义？
作为一个资深的互联网从业者，我要非常负责任的说，项目的好坏最根本的在于市场，而不是单纯的技术。
不可否认，技术对于一个产品来说非常重要，曾几何时，我也是非常的追求技术上的“高端”从而忘记了产品与市场、时间上的问题。因此，由于技术上的某些原因，导致了项目的延期甚至上线后发生一些比较严重的Bug。
后来，随着工作的时间越来越长，对于技术和产品的观念慢慢发生着改变。后来，我在一次工作中的经历，让我确实的认识到了，技术是为产品和市场服务的。
那时，我作为一个项目的负责人，全权对项目负责，为了让项目能够更快的上线，我使用了最简单的技术方案，使用最少的人力，让项目快速的上线了。由于项目的发展比较快，后期还上了物联网设备，使得在不断的迭代过程中，曾经的架构慢慢的无法支撑业务的增长。
这时，就面临需要重构了，而这个时期，团队有两个声音，一个觉得应该使用领域驱动设计（DDD）和查询和命令职责分离（CQRS）来重构，理由是因为，我们团队曾经对DDD有一定的研究，而且经过这么长时间，对于业务的理解已经非常深了，使用DDD能够很好的锻炼团队，并且让产品的技术底蕴很深厚。另一个是觉得，我们应该在服务化上做更多的优化，不改变现有的底层架构。
当然，我个人是不建议用DDD的，因为我当时自己对DDD的理解都不深，我相信团队大部分的人对于DDD都是一知半解，潜在的风险太大了。
但是，老板估计对现有的架构不是很满意，加上另一个技术的负责人大力的推荐DDD，因此最终就使用了这个方案，这导致使用了大量的人力在项目的重构上，对于业务上的迭代速度变得相当的慢。2个半月以后，业务的压力直接导致了这次重构的版本夭折了。
这次经历，让我在技术选型的时候更加的谨慎了，尽量不去使用自己不熟悉的技术方案，技术的创新前，需要做大量的实验。
再后来，我遇到了一个丰田的技术人员，他是做丰田的物流系统的。丰田的物流体系是全球数一数二的，也是少有的能够做到准时制物流的公司。按道理，这样庞大的系统，架构应该是非常复杂的才对。
但是，我在详细的了解后发现，并不是这样的。丰田的物流系统使用.NET
做的，基础的三层架构，连MVC都没有使用，甚至连分布式缓存都没有使用，性能差了，就加服务器。
丰田本来就不是一个互联网公司，是全球最大的汽车制造商，自然不愿意花太多钱养太多技术人员，但是服务器多花点钱是没关系的。这样技术方案其实是最适合丰田的，语气花一年上千万养一大群高端的技术人员，不如花几百万还买服务器呢。
因此，项目的好坏其实更多的还是看看这个项目是不是符合用户的需求，能不能解决用户的痛点，技术上是不是最适合产品的定位。并不是技术越高端就是越好的，而作为架构师，除了了解技术外，还需要了解业务，只有明白了业务的发展，才能够做出最适合的架构。