1. Algorithm: 每周至少做一个 LeetCode 的算法题

题目

59. Spiral Matrix II



Given a positive integer n, generate a square matrix filled with elements from 1 to n2 in spiral order.



Example:

Input: 3
Output:
[
 [ 1, 2, 3 ],
 [ 8, 9, 4 ],
 [ 7, 6, 5 ]
]



解答

思路：数字从0一直递增到n*n, 顺序是顺时针先转完外层，接着再转内层。类似于海螺🐚的结构。

明白这点就可以理解下面的代码了，要给出上下左右四个边界的index，一直按照顺序递增就好。



class Solution {
    public int[][] generateMatrix(int n) {
    	// init
        int[][] result = new int[n][n];
        // edge check
        if (n == 0) {
          return result;
        }
        int number = 1;
        int top = 0;
        int bottom = n - 1;
        int left = 0;
        int right = n - 1;
        while (top <= bottom && left <= right) {
          // top
          for (int i = left; i <= right; i++) {
            result[top][i] = number++;
          }
          top++;
          // right
          for (int i = top; i <= bottom; i++) {
            result[i][right] = number++;
          }
          right--;
          // bottom
          for (int i = right; i >= left; i--) {
            result[bottom][i] = number++;
          }
          bottom--;
          // left
          for (int i = bottom; i >= top; i--) {
            result[i][left] = number++;
          }
          left++;
        }
        return result;
    }
}



2. Review: 阅读并点评至少一篇英文技术文章



Reviewing the worst piece of code ever

https://www.micheleriva.it/posts/2020-07-31-reviewing-the-worst-piece-of-code-ever



这篇文章对下面屎一样的代码，进行剖析：

1. javaScript竟然做数据库查询，没有前后端分离；

2. 数据库的密码没有加密，那可以写个脚本，把所有用户名，密码都给遍历出来了；

3. "true" == "true" ，这还要啥判断条件；

4. 前端设置过期cookie，黑客如果设置为很大的值，那不就可以为所欲为。





3. Tips: 学习至少一个技术技巧

笔者写的博客：



解决XCode 11 build error 编译错误 image not found



问题描述

XCode 11，build app的时候，编译错误 image not found。



解决

[Xcode 11+]



Root Cause 在于framework的Embed选项要选择为 Embed & Sign。 路径如下：

Target -> General->Frameworks, Libraries And Embedded Content section.



确定有图片资源的framework选择 'Embed & Sign'， 默认的是 Do Not Embed .

[Xcode v6 -> Xcode v10]



Root Cause: 少加一些framework。

Target -> General->Frameworks, Libraries And Embedded Content section -> 增加 framework即可。



参考

https://stackoverflow.com/questions/24993752/os-x-framework-library-not-loaded-image-not-found



4. Share: 分享一篇有观点和思考的技术文章

笔者写的博客链接



极客大学架构师训练营 微服务架构 Service Mesh 服务网格 RPC 协议实现原理 Dubbo 通讯协议 第19课 听课总结



说明

讲师：李智慧



阿里早期微服务架构重构

单体应用，所有的服务都在一个War包里面发布，体积大约1.2G。

巨无霸应用系统带来的问题

编译、部署困难：

• 对于网站开发工程师而言，打包构建一个巨型应用是一件痛苦的事情。

• 也许只是修改了一行代码，输入 build 命令后，抽完一支烟，回来一看，还在 building；

• 又去喝了一杯水，回来一看，还在building；

• 又去了一次厕所，回来一看，还在building；

• 好不容易build 结束，一看编译失败，还得重来...

• 想砸了显示器有木有？

代码分支管理困难：

• 复用的代码模块由多个团队共同维护修改，代码 merge 的时候总会发生冲突。

• 代码 merge 一般在网站发布的时候，和发布等问题互相纠结在一起，顾此失彼，每次发布都要半夜三更。



数据库连接耗尽：

• 巨型的应用、大量的访问，必然需要将这个应用部署在一个大规模的服务器集群上，应用与数据库的连接通常使用数据库连接池，以每个应用10个连接计，一个数百服务器集群的应用将需要在数据库上创建数千个连接，数据库服务器上，每个连接都会占用一些昂贵的系统资源，以至于数据库缺乏足够的系统资源进行一般的数据操作。



新增业务困难：

• 想要在一个已经乱如麻般系统中增加新业务，维护旧功能，难度可想而知。

• 一脚踩进去，发现全都是雷，什么都不敢碰。许多新工程师来公司半年了，还是不能接受业务，因为不知道水有多深。

• 于是就出现这种怪现象：熟悉网站产品的“老人” 忙得要死，加班加点干活；不熟悉网站产品的信任一帮忙就出乱，跟着加班加点；

• 整个公司热火朝天，加班加点，却还是经常出故障，新产品迟迟不能上线。



解决方案就是拆分，将模块独立部署，降低系统耦合性：

解决方案就是拆分，将模块独立部署，降低系统耦合性：

• 纵向拆分：将一个大应用拆分为多个小应用，如果新增业务较为独立，那么就直接将其设计部署为一个独立的 Web 应用系统。

• 横向拆分：将复用的业务拆分出来，独立部署为微服务，新增业务只需要调用这些微服务即可快速搭建一个应用系统。



微服务框架

Web Service 与企业级分布式服务

• Service Provider: 服务提供者

• Service Requester：服务消费者，客户端

• Service Broker：服务注册中心。服务提供者注册服务到服务注册中心；服务消费者从服务注册中心请求服务，服务注册中心调用*服务提供者*，最终把结果返回给服务消费者。



数据格式是：XML，XML一半的数据都是冗余的，性能比较低下。



服务提供者通过 WSDL （Web服务描述语言，Web Services Description Language）向注册中心（Service Broker）描述自身提供的服务接口属性，注册中心使用 UDDI (Universal Description, Discovery, and Integration, 统一描述、发现和集成)发布服务提供者提供的服务，服务请求者从注册中心检索到服务信息后，通过 SOAP (Simple Object Access Protocol, 简单对象访问协议) 和服务提供者通信，使用相关服务。



Web Service 虽然有着成熟的技术规范和产品实现，以及在企业应用领域有许多成功的案例，但是也具有一些固有的缺点：

• 臃肿的注册和发现机制；

• 低效的 XML 序列化手段；

• 开销相对高的 HTTP 远程通信；

• 复杂的部署和维护手段；



这些问题导致 Web Service 难以满足大型网站对系统高性能、高可用、易部署、易维护的要求。



微服务框架需求

对于大型互联网系统，除了 Web Service 所规范的服务注册与发现，服务调用等标准功能，还需要微服务框架能够支持：

• 失效转移(Fail Over): 对于大型网站的微服务而言，即使是很少访问的简单服务，也需要集群部署，同时微服务框架还需要支持服务提供者的失效转移机制，以实现服务高可用。

• 负载均衡：对于集群部署的服务提供者，服务请求者可以使用加权轮询等手段访问，使服务提供者集群实现负载均衡。

• 高效的远程通信： 对于大型网站，核心服务每天的调用次数会达到数以亿计，如果没有高效的远程通信手段，服务调用可能会成为整个系统性能的瓶颈。

• 对应用最少侵入： 网站技术是为业务服务服务的，是否使用微服务需要根据业务发展规划，微服务也需要渐进式的演化，甚至会出现反复，即使用了微服务后又退回到集中式部署，微服务框架需要支持这种渐进式演化和反复。当然服务模块本身需要支持可集中式部署，也可分布式部署。

• 版本管理：为了应对快速变化的需求，服务版本升级不可避免，如果仅仅是服务实现升级，那么这种升级对服务请求者而言是透明的，无需关注。但是如果服务的访问接口发生变化，就需要服务请求者和服务提供者同时升级才不会导致服务器调用失败。企业应用系统可以申请停机维护，同时升级接口，而网站服务不可能中断，需要服务提供者先升级接口，并同时提供历史版本的服务供请求者调用，当请求者访问接口升级后才可以关闭历史版本服务。（阿里的对升级以后服务维护半年，半年以后就下线。）



微服务架构 (Dubbo)

1. 服务提供者 注册到 服务注册中心，把服务映射到服务提供者列表；

2. 服务消费者程序，调用服务接口；

3. 接口访问代理获取到服务消费者调用的接口；

4. 服务框架客户端，调用服务提供者列表找到服务提供者；

5. 负载均衡策略分配一个服务给服务框架客户端；

6. 远程通讯模块与客户端建立连接；

7. 远程通信模块，调用 服务调用线程；

8. 服务调用线程 请求服务提供者程序， 服务提供者程序返回服务的 class 给服务调用线程；

9. 服务调用线程 返回 class 给远程通讯模块；

10. 远程通讯模块 返回 class 给 服务框架客户端， 服务框架客户端 用 class 创建对象，调用里面的方法即可。