简书停更有一年多了. 这一年多一方面工作比较忙, 另外结婚, 家里装修每件事都很费精力, 的确是没有时间持续学习, 更新博客. 个人生活方面不细讲了, 工作上有一个蛮明显的感觉, 如果只是止步于每天完成自己的工作内容, 更多的是在输出价值. 工作上虽然也有知识输入, 但不成体系, 太零散. 所以后面还是尽力抽出时间, 多在简书上做一些总结分享, 希望能跟各位同行多多交流, 跟上时代发展.
最近一个项目是在做公司内部的流程引擎平台. 因为是面向全公司所有业务的, 不同业务线的二次开发能力, 开发资源, 性能要求, 稳定性要求, 业务部署架构差异很大. 在设计系统架构时, 如何结合公司现有的技术体系, 满足多种多样的业务需求成为设计时比较让人头疼的问题.
很长一段时间我都觉得系统架构是一种比较抽象, 比较 "玄学" 的东西, 不像代码运行结果, 要么对要么不对. 碰到问题时, 更多是靠经验, 直觉给出方案. 直到听了李运华老师的在极客时间上的《从 0 开始学架构》, 开始对架构设计有了一些更理性的认识.
首先为什么软件需要架构? 假设我们现在是一家初创公司, 业务刚上线, 日活用户不多. 这时我们一个代码工程, 一台服务器, 一台数据库就可以搞定. 但随着业务发展, 会带来以下问题: 1, 业务逻辑会越来越复杂. 2, 业务发展, 日活用户增加, 对系统的压力越来越大. 3, 用户增加, 对系统稳定性要求越来越高. 当代码越来越难以维护, 线上故障增加, 老码农就会跳出来说, 我们需要做一下架构治理了. 这时我们做架构治理的目的, 是解决业务发展引入的这些问题, 让技术能跟上业务的发展. 而最终的产出解决方案, 就是我们的系统架构视图. 第二, 既然软件架构是用来解决业务发展中遇到问题, 那如何定位问题? 李运华老师在课程中分享了问题的来源 (复杂度的来源): 高性能, 高可用, 可扩展, 安全, 成本, 规模. 并列举了遇到这些问题的常用解决方案. 架构设计并不是靠灵光一闪, 更多时候是站在已有经验上, 结合具体业务场景做改进. 另外李运华老师在课程中还结合案例分享了架构设计原则, CAP,BASE 理论, 开源项目的, 新技术的学习经验.
后续会更详细的学习李运华老师提到的常用解决方案, 并在《架构》文集下更新, 但作为对老师的尊重不会涉及课程内容. 如果想了解李运华老师的《从 0 开始学架构》, 可以关注我的公众号 "码去码归", 发送 "架构" 两字获取优惠二维码.
来源: http://www.jianshu.com/p/2c85f0f29651