文章插图
而部署方式 ， 只需要在双机房建立两套对等集群 ， 并另外建一个较小的灰度发布集群即可 ， 所有不同业务都运行在统一平台集群上 。
更细粒度的服务意味着每个服务的开发更简单 ， 代码量更小 ， 依赖更少 ， 隔离稳定性更高 。但更细粒度的服务也意味着更繁琐的运维监控管理 ， 直到今年公司内部弹性私有云、缓存云、消息队列、部署、监控、日志等基础系统日趋完善 ， 使得实施这类细粒度划分的微服务架构成为可能 ， 运维成本可控 。而从当初 1.0 的 1 种应用进程 ， 到 3.0 的 6、7 种应用进程 ， 再到 4.0 的 50+ 更细粒度的不同种应用进程 。每种进程再根据承载业务流量不同分配不同的实例数 ， 真正的实例进程数会过千 。为了更好的监控和管理这些进程 ， 为此专门定制了一套面向服务的运维管理系统 。
统一服务运维提供了实用的内部工具和库来帮助开发更健壮的微服务 。包括中心配置管理 ， 流量埋点监控 ， 数据库和缓存访问 ， 运行时隔离 ， 如下图所示是一个运行隔离 。
细粒度的微服务做到了进程间隔离 ， 严格的开发规范和工具库帮助实现了异步消息和异步 HTTP 来避免多个跨进程的同步长调用链 。进程内部通过切面方式引入了服务增强容器 Armor 来隔离线程 ， 并支持进程内的单独业务降级和同步转异步化执行 。而所有这些工具和库服务都是为了两个目标：
1.让服务进程运行时状态可见
2.让服务进程运行时状态可被管理和改变
最后我们回到前文留下的一个悬念 ， 就是关于消息投递模型的缺陷 。一开始我们在接入层检测到终端连接断开后 ， 消息无法投递 ， 再将消息缓存下来 ， 等终端重连接上来再拉取离线消息 。这个模型在移动时代表现的很不好 ， 因为移动网络的不稳定性 ， 导致经常断链后重连 。而准确的检测网络连接断开是依赖一个网络超时的 ， 导致检测可能不准确 ， 引发消息假投递成功 。新的模型如下图所示 ， 它不再依赖准确的网络连接检测 ， 投递前待确认消息 id 被缓存 ， 而消息体被持久存储 。等到终端接收确认返回后 ， 该消息才算投妥 ， 未确认的消息 id 再重新登陆后或重连接后作为离线消息推送 。这个模型不会产生消息假投妥导致的丢失 ， 但可能导致消息重复 ， 只需由客户终端按消息 id 去重即可 。
京东咚咚诞生之初正是京东技术转型到 Java 之时 ， 经历这些年的发展 ， 取得了很大的进步 。从草根走向专业 ， 从弱小走向规模 ， 从分散走向统一 ， 从杂乱走向规范 。本文主要重心放在了几年来咚咚架构演进的过程 ， 技术架构单独拿出来看我认为没有绝对的好与不好 ， 技术架构总是要放在彼时的背景下来看 ， 要考虑业务的时效价值、团队的规模和能力、环境基础设施等等方面 。架构演进的生命周期适时匹配好业务的生命周期 ， 才可能发挥最好的效果 。
【京东架构专家分享京东架构之路】京东峰值系统设计
有别于社交网络、搜索和游戏等网站 ， 电商网站的用户流量具有操作性强、随时令变化等特点 。在欧美国家 ， Black Friday和Cyber Monday标志着节假日消费的高峰 。影响电商流量峰值的主要因素是抢购、促销和恶意攻击 ， 尤其是京东618店庆和双11等大规模的促销活动 。高流量、高并发情况下 ， 如何保证整个系统的可靠性和稳定性 ， 是众多电商企业研发团队都在思考的问题 。
京东电商系统的设计是围绕系统稳定性、可靠性、高并发和可扩展性为核心开展的 。如何在峰值来临时 ， 保证用户有平滑流畅的体验 ， 且系统不会出现异常呢？我们先来看看京东系统的一些特点（图1） 。
文章插图
图1 系统架构庞大复杂
京东的业务种类繁多 ， 涉及SKU几千万种 ， 这使得系统庞大 ， 外部需要对接供应商、消费者和第三方商家三大板块 。内部系统包括了商品供应链中除商品设计和生产外的几乎所有环节 ， 包括登录、交易、后台、供应链、仓配、客服等 。所有这些涉及大小系统几千个 ， 造就了一个极其复杂庞大的体系 。除此之外 ， 京东系统交互强 ， 各个功能模块之间关联性强 ， 牵一发而动全身 ， 做任何修改都需要慎之又慎 。因此 ， 一切优化方案都以保持系统稳定为前提 。
推荐阅读
- 专家建议都市人多饮藏茶防三高
- 丹徒,茶叶专家现场解难 为茶业发展献策
- 架构师大神带你读懂C++
- 专家提示,茶饮料多含香精 饮用需适量
- 众茶界专家为中国乌龙茶红茶走向世界献策
- 京东618和双11哪个更便宜 京东618什么时候最便宜
- 专家与你起探讨饮茶之妙处
- 高并发服务器架构--SEDA架构分析
- 国家茶业技术体系专家行调查安化低氟茶品种
- 系统架构进化过程