软件架构阅读笔记14
青龙系统1.0:
实现了电商物流基础功能，满足了核心业务诉求。
青龙系统2.0:
已经成为完善的自营电商物流系统。
青龙系统3.0:
希望利用京东物流的优势，来带动POP平台体验的提升，以外单开放为主题。开发了青龙开放平台，接单系统，和主流的ISV软件完成对接，以及改造现有分拣，运输，配送等环节，来支持外单。
青龙系统4.0:配合公司战略，从零开始，构建了京东乡村推广员系统和校园派系统。
青龙系统5.0:互联网＋物流
青龙系统6.0:智慧物流
青龙系统发展到今天，已经包含了分拣中心，运输路由，终端，对外拓展，运营支持等五十余个核心子系统，构建了完善的电商物流体系。
高可用：
合适的架构方案
对于大多数应用，前端应用双机房集群部署，后端数据库系统采取成熟的主备从的模式，也就是单个机房作为写入，备库在另外机房，可以快速进行切换，读库双机房部署，是优选的方案。对于这个架构方案，存在跨机房写延长的问题，可以根据场景利用异步的方式进行解决，一般也是没有问题的。对于青龙系统来讲，也有些特别，利用分拣中心的本地服务器和操作人员的设备，实现离线生产，进一步提高可用性。
大系统小做、服务拆分：
对一个互联网服务，一般会首先完成最核心的功能，快速进行上线，不断进行迭代，后续再进行辅助功能跟进。对于核心功能，随着用户数的增加，会不断进行服务拆分，如何进行拆分，拆分到什么样的粒度，是不是微服务是解决问题的银弹？这些都要根据实际的应用场景来评估，绝不是越细越好，而是要达到一个优雅的平衡。
并发控制、服务隔离：
并发控制，现在已经成为互联网服务基本要求。从技术上，服务隔离，可以是硬件级隔离，全部隔离，也可以是前端应用的隔离。
灰度发布:
使得快速迭代成为可能，并且，很多服务因为各种原因线下也是很难测试的，只能在线上测试。如果没有灰度发布，只能全量发布，就存在较长测试周期问题，如果没有重复勉强上线，就存在很大的系统崩溃的风险。按照用户，区域进行灰度发布是比较常用的方法。
全方位监控报警:
可以分为技术层面和业务层面，技术层面包括对CPU，内存，磁盘，网络等的监控，业务层面，包括对处理积压量，正常的业务量等。做到全方位监控，才有可能在影响用户之前，提前解决问题，提升系统可用性。否则，等用户发现问题，在很大的压力下，技术团队更难处理，导致系统不可用时间加长。
核心服务、平滑降级：
对于核心服务来讲，能够平滑进行降级，提供基础的服务，也是非常重要的。对于青龙系统来讲，就利用分拣中心本地服务器和操作人员的设备，研发了离线生产系统，来应对集中服务万一不可用的情况。
