2018 年 2 月 28 日, 周三晚上 8 点 30 分, 前阿里架构师某商业银行北京研发中心负责人某电商公司高级技术总监的 kimmking 带来了主题为软件架构发展历程分享的交流以下是主持人天怡整理的问答实录, 记录了作者和读者间问答的精彩时刻
内容提要:
微服务架构中有哪些 framework 的 jar, 分别是怎么划分的?
微服务架构实际体现的是组织的结构, 对于微服务架构自身的演进, 现在是什么规律?
请问初次接触一个中等到复杂程度的项目时, 如何快速熟悉其架构?
技术选型时, 那么多的框架, 怎么知道哪个适合?
架构设计需要一开始就大体结构设计并且固定好吗? 实际在开发过程中可能会增加新需求, 这个新需求可能会需要架构的修改, 如果在原来的架构基础上迭代开发, 开发的时候会有非常勉强的感觉遇到这种情况的时候怎么处理才更好?
初期评估项目, 设计架构的人留了坑, 作为后续负责项目的人, 想优化架构, 应该怎么办?
初次接触一个中等到复杂程度的项目时, 如何快速熟悉其架构?
遇到问题扩容服务器配置或数量, 我想问下这样简单的架构好, 还是将业务进行架构上分拆分, 应该如何衡量综合考虑呢?
问: 微服务架构中有哪些 framework 的 jar, 分别是怎么划分的?
答: 此问题其实是开发和部署的问题用 jar 的角度去看, 不如从子项目和部署单元的角度来看一般来说, 我们把系统拆分成多个不同的独立的微服务, 这个层次上, 自动就划分成了多个单元然后每个微服务作为一个子项目, 开发期的项目结构是可以再次划分的如果子项目也相对复杂, 可以拆分成更多个 sub project 但是每个子项目作为一个服务, 是需要部署到一个容器的
问: 微服务架构实际体现的是组织的结构, 对于微服务架构自身的演进, 现在是什么规律呢?
答: 这其实说得是康威定律 (Conway's Law) 原来的意思是团队的组织方式必然影响了系统的设计方式这其实是一个很显然的问题我们也可以进一步延伸一下: 每一个系统都是为其所有的用户服务的, 这些用户的角色决定了他们在系统里能操作的功能, 所有的角色和功能串起来就是所有的业务流程, 这些组织形式是系统设计最直接的体现在研发团队这里也是一样, 一个分散的团队可能采用一种分散的架构设计, 团队的沟通方式势必对系统组件的拆分和组合产生影响
问: 请问初次接触一个中等到复杂程度的项目时, 如何快速熟悉其架构?
答: 项目的范畴比代码大我们先说熟悉代码架构源于业务, 了解业务是基础然后接触到一个新项目的代码, 如果有相关设计文档, 最好先看看文档, 对于有疑问的地方, 找当事人问是最高效的办法熟悉具体的代码的话, 一个是看整体代码结构, SSHSSM 的 MVC 结构也好, DDD+ 微服务方式的代码结构也好, 了解了结构看具体代码就可以知道这一块代码在所有代码里处于什么位置, 起什么作用再详细看使用的各个技术细节还有一个就是, 最好要把系统跑起来, 主要业务场景 debug 单步跟踪调试一遍, 这样就知道你看的想的东西是不是跟实际的一致如果是项目的话, 还需要了解各种非功能需求和实际的部署架构等
最后一点是平时多看优秀的项目代码, 特别是知名开源项目, 看得多的想的多了, 经验自然多了, 一般的项目就不在话下了
问: 技术选型时, 那么多的框架, 怎么知道哪个适合?
答: 框架的技术选型问题是一个非常常见的问题比如 Mybatis 和 Hibernate,Struts 和 SpringMVC,Tapestry 等一个成熟的框架, 都是经过非常多的项目验证过的, 使用熟练了感觉区别不大没有使用熟练的情况下, 选择最成熟的案例最广的文档最多的上手最快的非常熟练了, 而且团队的技术能力不错的情况下, 选择自己比较能更好控制的, 有能力完全 cover 的, 跟自己的整个研发技能积累沉淀的基础设施融合的最好的比如说自己基于 Mybatis 做了一些封装, 实现了一些代码生成工具等框架都是别人的, 用熟了也还是别人的, 只有继续发展形成自己的武器库才是自己的
问: 架构设计需要一开始就大体结构设计并且固定好吗? 实际在开发过程中可能会增加新需求, 这个新需求可能会需要架构的修改, 如果在原来的架构基础上迭代开发, 开发的时候会有非常勉强的感觉遇到这种情况的时候怎么处理才更好?
答: 软件架构设计作为一个领域专门发展开来, 就是为了总结经验便于以后更加灵活, 更好扩展, 更好维护无论是 MVC 的划分, 还是组件化, 服务化, 到现在的微服务架构因为我们的系统需求和流程本身, 我们的业务外部市场竞争环境, 我们客户的实际需要, 都是在不断发展变化的, 系统必须跟着一直发展变化我在文章里提到了, 设计必须有一定的前瞻性, 架构是需要不断发展变化的类似我们做业务规划或技术规划, 我们需要适当考虑以后几个月半年一年甚至再长一点的长远考虑不仅是需求, 还包括系统的非功能性需求, 比如性能, 扩展性这需要我们对原本的业务有足够的拆解和抽象能力, 形成某种业务和系统的架构模式如果具体到代码层面, 那就是很多的优秀代码设计的经验, 我们一般称为设计模式, 大家需要灵活应用各种设计模式(比如 GoF 的 23 个设计模式等)
问: 初期评估项目, 设计架构的人留了坑, 作为后续负责项目的人, 想优化架构, 应该怎么办?
答: 这实际上是两个问题, 一个是怎么填坑, 一个是怎么从技术到架构师
填坑的事儿, 在哪儿都有, 不仅仅是软件开发这件事儿上处理办法一般就是搞清楚坑有多少, 问题有多严重, 坑在哪儿, 处理办法都有哪几种, 解决的代价分别有多大当然这个评估本身需要对项目非常了解, 也需要花费很多时间精力作为一个接手项目的负责人, 这个时间是你必须去争取的, 不然在你手上雷随时会爆炸
怎么成为架构师, 这是职业规划问题如果你有兴趣, 有志向成为架构师, 那么请认真对待你经手的每一个项目, 努力从每一个技术问题考虑最优解并去尝试改进, 努力从自己负责的模块之上更大视角的去考虑和分析问题, 努力学习各种层出不穷的新技术和新思想, 努力去阅读和理解优秀项目的架构设计和代码 (特别是知名开源项目代码) 还有就是积累, 积累自己的知识面, 在某一方面的具体领域成为专家我的文章中也提到了, 技术领域是符合一万小时定律的不断努力的读写, 思考, 突破自己, 你一定会是一个优秀的架构师
问: 初次接触一个中等到复杂程度的项目时, 如何快速熟悉其架构?
答: 项目的范畴比代码大我们先说熟悉代码吧架构源于业务, 了解业务是基础然后接触到一个新项目的代码, 如果有相关设计文档, 最好先看看文档, 对于有疑问的地方, 找当事人问是最高效的办法熟悉具体的代码的话, 一个是看整体代码结构, SSHSSM 的 MVC 结构也好, DDD + 微服务方式的代码结构也好, 了解了结构看具体代码就可以知道这一块代码在所有代码里处于什么位置, 起什么作用再详细看使用的各个技术细节还有一个重要的就是, 最好要把系统跑起来, 主要业务场景 debug 单步跟踪调试一遍, 这样就知道你看的想的东西是不是跟实际的一致如果是项目的话, 还需要了解各种非功能需求和实际的部署架构等
最后一点是, 平时多看优秀的项目代码, 特别是知名开源项目, 看得多的想的多了, 经验自然多了, 一般的项目就不在话下了
来源: http://blog.csdn.net/kimmking/article/details/79441144